In questa seconda puntata parleremo di PTP, Payload e latenze. Chi si fosse perso la prima è invitato a “recuperala” qui.
Capiremo alcuni aspetti fondamentali basandoci su concetti già familiari grazie alle nostre esperienze nel mondo dell’audio digitale, capendo cose c’è di analogo (non ho detto analogico…) e cosa invece è diverso quando ci si cimenta in trasmissioni AoIP o AoEthernet.
Non è certo possibile o utile scendere ad elevati livelli di dettaglio tecnico che poco aiuterebbero a capire cosa fare e cosa serve a chi si appresta a divenire un utilizzatore, ma è inevitabile che leggendo ci si imbatterà in termini e concetti nuovi che impareremo ad assimilare per gradi.
PTP
PTP – Precision Time Protocol è il nome comune dello standard IEEE 1588, pubblicato per la prima volta nel 2002. Definisce un protocollo per i messaggi che diversi dispositivi di rete possono scambiare tra loro per sincronizzare i loro “orologi”. La pubblicazione più recente dello standard raggiunge elevata accuratezza, attraverso la combinazione di tecniche hardware di time stamping dei pacchetti e calcoli del ritardo accumulato. Oggi siamo ben al di sotto del microsecondo e questo rende il PTP adatto anche per applicazioni audio e video over ethernet.
Qualcuno non avrà mica pensato che il PTP sia stato inventato per noi audio/videofili vero? Di certo no! Infatti il PTP nasce per evitare che Alok da Mumbai pretenda di essere arrivato prima di James da Londra nel piazzare l’ordine delle azioni Apple al NASDAQ di New York senza averne le prove…
Cosa serve allora a noi il PTP e che relazione intercorre tra esso e il nostro “buon vecchio” word clock?
Il Word Clock, nel nostro mondo audio digitale, rinfresca in tempo reale a tutti gli apparati l’idea di “quanto dura un secondo”, magari dividendolo in tantissime sottoparti (48.000 quando si lavora a 48kHz) ognuna delle quali presuppone lo spostamento o il trasferimento “sincrono” di un audio sample.
Torniamo adesso all’esempio pretendenti dei nostri amici giocatori di borsa… Basterebbe al nostro Alok sapere quando dura un secondo per avere la meglio su James e convincere il NASDAQ che le azioni Apple appena ordinate sono sue? Temo di no!
Per dirimere la questione, Alok, James e il NASDAQ devono sapere con la massima precisione non solo che ora è adesso, ma anche che ora era quando sono stati piazzati gli ordini e tutti devono avere gli orologi perfettamente “allineati”.
Sempre dalla nostra esperienza di audiofili, un’informazione simile ci veniva data dal TIME CODE (o SMPTE, MIDI TIME CODE, LTC, …) ovvero da un segnale posizionale che ci dicesse non tanto quanto dura un secondo (per quello avevamo il clock) ma “che ora è adesso” in modo che alla tale ora, minuto, secondo e frame partisse il video contemporaneamente all’audio, avvenisse il GO della tal cue nella console luci e magari anche si accendesse la miccia di lunghezza pre-calcolata per i fuochi d’artificio.
Ottimo! Il PTP offre contemporaneamente entrambe le informazioni, ossia scandisce il tempo che passa (che ora è adesso) con una granularità elevatissima (come detto ben al di sotto del microsecondo) e, come effetto collaterale, ci ricorda anche “quanto dura un secondo”, soppiantando nel mondo ethernet i nostri amati word clock e TIME CODE in un solo colpo!
Come anticipato non è questa la sede nella quale scendere a dettagli tecnici non necessari alla comprensione, procediamo per gradi e ci limitiamo ora ad alcune considerazioni che agevoleranno l’esperienza dei nuovi utilizzatori.
Nella prossima puntata, quando parleremo di interoperabilità e AES67, aggiungeremo altri dettagli relativi al PTP, soprattutto perché Dante e Q-NET utilizzano la prima versione (V1) mentre Ravenna, LiveWiire e AES67 la V2 e capiremo come si possa ovviare al “problema”.
In futuro, d’accordo con la redazione, potremmo anche tornare sull’argomento PTP con approfondimenti dedicati.
I dispositivi di rete (switch, router, ecc) sono generalmente considerati come pezzi che costituiscono il tessuto sottostante alla rete. Questi, dal punto di vista del PTP, sono detti ‘Boundary Clocks’. Apparati audio/video, DAW ecc. hanno più probabilità di essere dispositivi terminali e questi sono vanno sotto il nome di ‘Ordinary Clock’.
E’ importante sapere che, a differenza del Clock che in sistemi di trasmissione sincrona era univoco, di PTP presenti in una infrastruttura Ethernet ne possono convivere molti, di forme diverse (denominate profili o meglio profile, in inglese), organizzati in diversi “domain” e capire come i vari apparati arrivino a determinare chi deve essere il master, funzione che in gergo PTP prende il nome di GRANDMASTER.
Il Grandmaster fornisce il clock sul quale tutti gli altri apparati si “sincronizzeranno”, analogamente a quanto avviene per il Clock Master nel mondo che già conosciamo.
Un dispositivo dotato di PTP si avvia nello stato di “ascolto” in attesa di messaggi PTP nel segmento di rete a cui è connesso. Se nessun messaggio PTP arriva dopo un periodo di tempo predeterminato (noto come Announce Timeout Interval) tale dispositivo si “autoproclama” Grandmaster. Se invece all’avvio arriva un messaggio di annuncio, il dispositivo deduce che in rete è già presente un master e si adegua al ruolo di slave, ma lo fa in maniera critica, ovvero lo accetta a condizione che il proprio clock sia effettivamente di qualità inferiore rispetto a quello fornito dal master.
I messaggi di annuncio includono infatti anche informazioni sulla qualità del clock proposto da chi lo invia. Se un dispositivo riceve un messaggio di annuncio e determina che il suo clock è più preciso, allora assumerà il ruolo di Grandmaster informando l’ex di adeguarsi al ruolo di slave.
Questo meccanismo non solo garantisce sempre il miglior clock possibile in tale porzione di rete, ma offre anche ridondanza “a palate”, in quanto ciascun apparato può sempre intervenire al grido di “morto un papa, se ne fa un altro” e sopperire alla scomparsa del Grandmaster.
Il “conclave” avviene in maniera rapida e indolore, i device orfani del vecchio Grandmaster scambiano un po’ di messaggi e ben presto eleggono uno di loro, anzi, il migliore tra loro.
Questo processo è noto come Best Master Clock Algorithm (BMCA). Gli operatori o i designer possono intervenire sulla gerarchia assegnando priorità a taluni apparati, attraverso le opzioni “Preferred Master”, “Auto” e “Slave only” solitamente presenti negli apparati dotati di PTP.
In figura (tratta dal sito Luminex) è riportato un esempio di ciclo semplificato del BMCA.
Interessante… ma visto che nella stessa rete Ethernet possono coesistere flussi a 44.1, 48, 88.2, 96 kHz etc, avranno bisogno di PTP differenti?!
Non è assolutamente detto o necessario!
Come abbiamo più volte ripetuto, il PTP, proprio come il clock, ti dice “quanto dura un secondo”, sta poi ad ognuno decidere in quante parti frazionarlo o, per meglio dire, quanti samples trasferire in quel lasso di tempo.
Qui rispunta in tutta la sua evidenza la relazione tra FS (frequenza di campionamento) e Clock, che ovviamente è di “parentela”, ma non sono la stessa cosa.
Un flusso a 96kHz è sincrono con uno a 48kHz quando condividono lo stesso riferimento di clock, ovvero quando hanno la stessa identica opinione su quanto duri un secondo e a ricordare loro tale misura in tempo reale è lo stesso soggetto.
TIME STAMP
Come è possibile garantire accuratezza di fase e allineamento temporale di flussi audio (intrinsecamente sincroni tra loro) quando provengono da diverse sorgenti e sono smistati da una rete che per costruzione è basata sulla trasmissione a pacchetti e in modalità totalmente asincrona?
Qui entrano in gioco il TIME STAMP e i buffers. Cerchiamo di capire in poche e semplici parole come funzionano.
Sappiamo che per mezzo del PTP tutti gli apparati di rete sanno esattamente “che ora è adesso” e “quando dura un secondo”. Sappiamo però che non c’è alcuna certezza di quanto tempo impiegherà un pacchetto di dati spedito dal produttore per arrivare al consumatore, specie se esso dovrà attraversare un numero indefinito e variabile di switch o, peggio ancora, se pacchetti che devono essere considerati “sincroni e allineati” faranno percorsi diversi per arrivare a destinazione, sapendo poi che tali tempi dipendono dal traffico di rete e da altri fattori.
L’unica certezza che abbiamo è l’ora esatta di creazione dei pacchetti, ma non quella di arrivo, per cui ogni apparato che processa audio ha l’obbligo di stampare su ogni pacchetto (TIME STAMP) l’ora esatta (fornita dal PTP) nel quale quel pacchetto è stato confezionato (badate bene, non quando ha iniziato il suo viaggio attraverso la rete, ma quando i bit audio sono stati impacchettati in Ethernet frames, precisazione che sarà più chiara in futuri approfondimenti).
In questo modo chi riceve pacchetti ha la possibilità di riallinearli tutti, visto che ciascuno porta chiara l’indicazione di quando è stato creato.
Siccome la durata del viaggio di ogni pacchetto è variabile (entro un certo ordine di grandezza, ovviamente) occorre che il ricevente abbia memoria sufficiente (buffer) per parcheggiare temporaneamente i pacchetti che arrivano prima degli altri in attesa dei “ritardatari” e garantire il perfetto allineamento temporale (e di conseguenza di fase), ricostruendo l’intero contenuto informativo audio prima di “suonarlo” in output.
E’ ovvio che “il primo che arriva aspetta”, esattamente come accade a me quando ho un appuntamento con mia sorella (solo che in quel caso sono sempre io che aspetto, mia sorella ha grossi problemi di PTP…) e che il tempo totale che intercorre tra quando l’audio è entrato in rete e quando ne esce, ovvero la latenza totale, risente non solo dei tempi di impacchettamento e viaggio, ma anche della lunghezza dei buffers che mittente e ricevente ha dovuto “aggiungere” per garantire il perfetto allineamento di tutte le componenti. Il mittente ha bisogno di buffer per “parcheggiare” dati audio a sufficienza per “riempire” un Ethernet frames e poi spedirlo, il ricevente ha bisogno di buffer per le operazioni di riallineamento dei vari pacchetti in arrivo, come ben schematizzato nella figura che segue.
PAYLOAD, LATENZE E EFFICIENZA DI TRASMISSIONE
Chi ha frequentato uno dei miei seminari sa bene che mi piace utilizzare parobole (similitudini) per spiegare in maniera semplice concetti intrinsecamente difficili o non immediati.
Recentemente ne ho inventata una anche per far capire a noi, abituati più a scaricare bilici di materiale audio che scaricare dalla rete e leggere PDF scientifici, che relazione intercorre tra payload, efficienza di trasmissione e latenza e ve la vado a raccontare.
Immaginiamo di avere tutto il materiale audio che servirà per il nostro spettacolo in piccoli ‘pezzi’ trasportabili singolarmente anche con una serie di Scudo (o altri piccoli VAN di marchi concorrenti a FIAT) e non solo con motrici o bilici . Se tralasciamo tralicci di alluminio e strutture ingombranti (infatti ho detto “il materiale audio”) oggi con l’avvento di Line Array compatti, ampli in classe D, console digitali “liofilizzate”, fibre ottiche al posto di ingombranti multicorde, non siamo poi tanto distanti dalla realtà!
Supponiamo che il magazzino dal quale il materiale deve partire e la venue nella quale avverrà il concerto distino 300 Km e che, ovviamente, i due luoghi siano collegati da una serie di strade, superstrade e autostrade.
Dovendo “muovere” un totale di 240 q.li di materiale, secondo quali parametri sceglieremo se utilizzare un solo bilico (magari stivato a tappo, ovviamente andando in terza fila), due motrici da 100 q.li e una da 50 q.li o 30 Scudo che possono trasportare ciascuno 8 q.li?
Le motrici le avremmo di proprietà o dobbiamo comunque rivolgerci a terzi? Abbiamo almeno tre autisti a disposizione? Ne abbiamo 30 se decidessimo per gli Scudo?
Quanto ci costano le varie opzioni?
Se vogliamo portare la nostra ‘parabola’ verso la comprensione del payload dobbiamo farci domande di tipo diverso:
- quanto tempo abbiamo da quando iniziamo il carico dei mezzi in magazzino a quando inizia il sound-check?
- Quanto traffico nelle strade siamo disposti a creare per effettuare i trasporti?
Ovvio che se dobbiamo aspettare che il bilico sia stipato prima di poter partire, attendere che completi il viaggio (alla velocità max di 80Km/h), una volta arrivato deve essere completamente scaricato (non si riesce sempre a caricare il materiale secondo l’ordine inverso di opportunità di scarico…) per poi iniziare a montare il tutto, ci vorrà molto più tempo rispetto ad un trasporto “agile” eseguito con 30 Scudo in serie, ognuno dei quali è caricato con il materiale che appena arrivato sarà montato e viaggerà ad una velocità media nettamente superiore rispetto al bilico.
Serve anche l’esempio intermedio delle tre motrici? No, siamo tutti esperti di “trasporti” e abbiamo già capito dove si vuole arrivare!
Così come nel caso del trasporto dei materiali (tipica frase che si trova in mezzo alle parabole…) quando dobbiamo trasportare un certo ammontare di dati audio dal trasmettitore al ricevitore, alcune soluzioni AoIP (ad esempio Ravenna) ci danno la possibilità di “caricare a tappo” ogni Ethernet frame che inviamo (bilico) o farli viaggiare “leggeri” (motrici) o “leggerissimi” (Scudo) caricando ciascun frame con pochi o pochissimi byte di audio.
Il Payload è dunque l’ammontare di byte audio che si decide di trasmettere per ogni Ethernet frame.
Secondo lo standard MTU, la dimensione massima di un Ethernet frame è di 1500 bytes.
Quando impacchettiamo i dati audio utilizzando il protocollo RTP, una parte di esso ha dimensione fissa (Headers) mentre la parte più importante è a dimensione variabile, come ben visibile (in verde chiaro) nella figura che segue.
Se utilizzeremo pacchetti piccoli avremo latenze migliori (più basse), ma creeremo più traffico in rete, diminuendone l’efficienza di trasmissione.
Se utilizzeremo pacchetti di grandi dimensioni, avremo latenze peggiori (più alte), ma creeremo meno traffico di rete, ottimizzandone l’efficienza.
Facciamo esempi molto pratici, analizzando diversi streams in formato Ravenna.
La dimensione fissa dell’header è di 40 bytes, pertanto 1500-40=1460 è il payload massimo che potremo inviare in un singolo Ethernet frame.
Un po’ di definizioni ci aiuteranno a capire meglio:
Audio Block = (numero di canali) x (sample). La dimensione dell’audio block dipende sia dalla codifica (16 o 24 bit) che dal numero di canali per stream.
Payload (in byte) = Audio Blocks / 8
Overhead (in byte) = parte fissa iniziale dell’Ethernet frame, per Ravenna pari a 40 Bytes
Ethernet Frame size = Overhead (fisso) + Payload (variabile)
Se vogliamo allora trasmettere due canali con la codifica PCM a 24 bit a 48 kHz:
(24bit per sample) * (2 canali) = 48 bit = 6 bytes. Questo è il più basso Payload utilizzabile in un singolo Ethernet frame e per trasmettere un secondo di audio ne dovremo inviare 48.000, con una latenza molto bassa pari a 20.8 microsecondi (più bassa del MADI, siete sorpresi?) e un efficienza di banda bassissima, pari allo 0,4%.
Se invece, per lo stesso secondo di audio a 24bit/48kHz, carichiamo l’Ethernet frame con il massimo Payload (1440 bytes, che trasporta 240 audio blocks) ne dovremo inviare “solo” 200, con un valore di latenza molto più importante (5 millisecondi) ma con altissima efficienza di banda, pari al 94%.
Possiamo anche decidere valori intermedi di Payload giocando sul compresso latenza Vs efficienza di banda.
Come ben riassunto in figura, se il numero dei canali da trasmettere contemporaneamente per mezzo dello stesso stream aumenta, il range di scelta si restringe.
Vediamo che il valore minimo e massimo di audio blocks per uno stream di 64 canali varia da 1 a 7, così come il payload parte già più alto (192 bytes – per forza ho 64 canali anziché due!) e per questioni di multipli esatti ci dobbiamo fermare a 1344 bytes.
Notiamo che la latenza più bassa è uguale al caso dello stream a due canali (giusto, ho lo stesso numero di audio blocks ma la pago in termini di minore efficienza) mentre quella “peggiore” è comunque migliore del caso a due canali. Perché? Ovvio, perché sono costretto ad impacchettare al massimo 7 audio blocks per frame (non ce ne stanno di più per 64 canali) e come conseguenza arrivano prima della coppia stereo che viaggia in gruppi di 240 audio blocks per frame, “pagando” la differenza in termini di efficienza di trasmissione.
Se voglio trasmettere uno stream di 128 canali ho pochissime alternative, da 1 a 3 audio block per frames, con basse latenze e buona efficienza di trasmissione.
Direi che per oggi può bastare, buona “digestione” e alla prossima puntata, nella quale parleremo di interoperabilità reale, AES67, SMPTE ST2110 – 2022-7 e ridondanza.
A presto!
Luca Giaroli
