Word Clock e altro …

di Marco Mocellin

Gli ultimi mesi sono stati densi di avvenimenti, tecnici e mediatici, inerenti il mondo del digitale e dell’audio networking in genere, spaziando dalla presentazione al mondo dei tecnici di nuove macchine, rivisitazione di protocolli e standard, iniziative di formazione e lancio di campagne di informazione volte ad integrare tutto questo in sistemi interamente digitali e commercialmente funzionanti.

Più in piccolo, per quello che riguarda la comunità che ruota intorno a Sound&Lite possiamo annoverare il primo corso sull’Audio Networking, a cui molti hanno partecipato di persona e altri in forma differita con la lettura del materiale del corso.

Personalmente, come spesso capita a chi espone ad un auditorio attento e professionale come quello che ho incontrato a Gabicce, resta spesso la sensazione di non aver comunicato tutto quello che potevo (o forse credevo di potere), o comunque di poter fare di meglio e di più.

Forse è solo un effetto della passione che si mette nell’esporre e nel rendere gli altri partecipi dei propri successi e insuccessi professionali. Non so, diciamo che questo articolo prende lo spunto proprio dalla sedimentazione di queste sensazioni ormai passate e vuole darmi la possibilità di approfondire e rendere più organici alcuni concetti che forse si sono smarriti nel mare della mia presentazione al corso.

In particolare, dopo aver descritto i protocolli e le relative implementazioni industriali mi piacerebbe parlare più diffusamente delle difficoltà e opportunità che si possono cogliere nel costituire sistemi complessi basati sulla trasmissione e condivisione delle informazioni audio in formato sempre digitale.

Infatti qui sta il punto: non è importante, secondo me, concentrarsi molto sulla possibilità di implementare un singolo link o una connessione tra due macchine o sistemi in digitale, quanto guardare veramente in avanti alla interoperabilità di sistemi complessi, possibilmente multimarca e multiprotocollo tra loro.

Non vedo come reale innovazione, anche di mentalità, l’utilizzo di un sistema composto da apparati dello stesso produttore in osservanza pedissequa delle richieste del produttore stesso, quanto la acquisizione di reale competenza specifica sui protocolli e sulle funzionalità che i vari sistemi di trasporto e processamento possono offrire. Tipicamente la fortuna premia gli audaci, non gli esecutori dei manuali di istruzione, anche se la sfortuna premia spesso ed inesorabilmente chi non li legge…

Per questo vorrei affrontare alcune delle principali problematiche che si presentano a chi volesse osare tanto in alto nel digital domain.

Una delle caratteristiche principali del mondo digitale, rispetto all’analogico, è che nel trasferimento di segnali digitali il sistema audio vive sincronizzandosi su una propria dimensione temporale che è diversa e distinta dal quella del mondo “esterno” al sistema. In parole povere: il sistema funziona fintanto che riesce a dare un senso ai dati in arrivo, cioè fintanto che riesce a restare sincrono con tutte le differenti parti di se stesso.

È un po’ come mantenersi coerenti con se stessi in ambito psicologico, non sempre è facile.

Ecco perché chi si accosta al mondo del digitale prima o poi si imbatte in situazioni in cui deve decidere a proposito dei sincronismi, che il sistema operi su base digitale tradizionale (protocolli molto noti: AES/EBU, PCM o altri) o su network (Ethernet based, ATM, altri) poco cambia, una informazione di sincronismo deve comunque venir generata e condivisa da tutto il sistema in maniera affidabile e univoca.

Per essere ancora più precisi – e riferendomi specificatamente al protocollo EtherSound o Cobranet – il problema è intrinsecamente risolto dagli apparati stessi finché la rete resta solo un sistema di trasporto senza alcuna connessione digitale con il mondo esterno; i “dolori di panza” iniziano nel momento in cui si ha la pretesa di sincronizzare il sistema audio con un clock proveniente da altri sistemi o, come nel caso di grossi network, di utilizzare il sistema di trasporto audio come tramite per la veicolazione del clock tra apparati che lavorano su protocolli differenti.

Tanto per essere meno fumoso, provo a fare due esempi più concreti.

Pensiamo ad una situazione in cui si abbia un gruppo di convertitori di ingresso (A/D), linkati ad un mixer digitale tramite un sistema proprietario fornito dal fabbricante dei convertitori e del mixer, poi ipotizziamo che l’uscita del mixer principale, collegata magari ad un mixer secondario, venga trasferita tramite un link che sia EtherSound o Cobranet, e poi di rientrare in apparati di processamento che siano linkati secondo lo standard proprietario iniziale del fabbricante.

Come potete immaginare il tutto deve funzionare in sincrono, però con un tramite per i segnali e per i sincronismi che non sia dello stesso “mondo” dei due sistemi.

Procedendo con ordine, diciamo subito che non ha rilevanza alcuna il tipo di standard dei sistemi interconnessi, quello che ha un senso valutare è il bitrate dei segnali, quindi in definitiva la velocità di campionamento dei sistemi e la quantità di campioni inviati per secondo per canale; questo serve in forma grossolana a capire qual è il componente più debole della catena, cioè quale può essere il miglior livello qualitativo (con tutte le eccezioni del caso nella correlazione qualità del segnale/bitrate) ottenibile dal sistema nel suo complesso.

Determinato questo parametro resta da decidere a quale velocità esercire il sistema. Banalmente, non posso far funzionare a 96 kHz una rete che prevede al massimo 48 kHz; potrei però campionare a 96, mixare a 96 (se credo…) registrare a 96 e poi declassare con conversione a 48 e diffondere in sala o dove credo sul network a 48.

In questo senso allego per curiosità alcune tabelle relative alle performance di Cobranet e EtherSound, senza voler essere esaustivo ma solo per far notare il livello di complessità sottostante a certe scelte tecniche.

Tornando al nostro progettino, resta ora da determinare che giro devono seguire i segnali nel network, e questo potrebbe essere semplice, va poi deciso che gerarchia debba avere il sistema di propagazione e diffusione del clock.

Tipicamente, infatti, le apparecchiature che determinano il master clock del sistema sono i convertitori di ingresso, ma potrebbe anche esserci un master clock generator che ripartisce in modo unico il clock della rete, e spesso sarà così in sistemi complessi.

Se facciamo comandare i convertitori di ingresso utilizzeremo una semplice struttura a catena: i convertitori comandano e tutto il resto della rete a valle si adegua. Teniamo presente che il primo mixer riceverà il clock dai convertitori, lo ridistribuirà al network (alla velocità giusta, 96 o 48 kHz che dovremo decidere e settare volontariamente) e potrebbe anche distribuire clock ad altre macchine – ad esempio registratori digitali connessi direttamente – o ad altri network operanti in altro modo e con differenti velocità di clock. Ovviamente, in relazione anche al tipo di protocollo, dovremo decidere su quali canali o “marker” temporali sincronizzare il sistema.

Molti sistemi di distribuzione audio su rete utilizzano schede di espansione per macchine di diversi produttori, potrebbe essere necessario documentarsi sulle modalità dei selezione dei giusti riferimenti all’interno dei software di gestione delle macchine; spesso, infatti, si tratta di sapere dove si trova la giusta finestra sul software delle macchine, oltre che di sapere cosa impostare.

In questo senso non sempre è opportuno affidarsi alle modalità di autosensing che, anche se sono sempre più performanti e veritiere nella determinazione della struttura di rete, a volte possono nascondere alcuni aspetti e alcune decisioni che potrebbero rivelarsi vincenti in caso di necessità. Vedremo perché.

Se invece il clock è distribuito centralmente tramite sistemi dedicati – distributori di clock, link AES/EBU con alcuni canali utilizzati solo come distributori di segnale di sincronismo o simili – il tutto è più semplice da organizzare a patto di disabilitare praticamente tutti i sincronismi interni delle macchine, cioè tutte acquisiranno un ruolo di slave in relazione all’ingresso external clock (con rispetto di tutti i formati previsti, soprattutto a livello di cablaggio).

Quest’ultima impostazione sembrerebbe la più tranquillizzante ma in realtà può rivelarsi estremamente pericolosa se non gestita opportunamente. Pensate a cosa potrebbe succedere se durante le prove, dopo aver selezionato come sorgente per il clock l’ingresso external, il sincronismo dovesse venire meno per qualche secondo e le macchine dovessero automaticamente selezionare un ingresso valido alternativo, ad esempio quello proveniente dal network stesso.

Probabilmente nessuno si preoccuperebbe o accorgerebbe di nulla ma è probabile che il network si porti in uno stato non controllato, cioè potrebbe diventare difficile capire chi sta comandando cosa e, fattore ancora più critico, potrebbe non essere semplice determinare cosa succederebbe in caso di anomalia su un apparato. E ovviamente, funzionando tutto, nessuno si occuperebbe della faccenda fino alla temuta anomalia.

Quindi il consiglio è di occuparsi del clock come ci si occupa dei segnali “udibili” perché se è vero che senza segnale non si sente nulla è anche vero che senza clock si sente ancora meno… Diciamo che non è più così vero che quello che funziona (vedi suona) stia funzionando regolarmente.