Protocolli e schede "Audio over IP"

[marcoc1712]

Che protocollo usa Linn nelle sue casse attive multiamplificate?

Non so nello specifico (hai un link al prodotto?), ma Linn ha inventato OpenHome.

EDIT: Se ti riferisci al sistema di collegamento Exact Link, NON è Tcp/IP, usa il cavo ethernet per trasferire i dati digitali, ma mediante un protocollo proprietario non compatibile e non mixabile con il traffico ethernet. Il 'media è il cavo cat5 o 6 e gli spinotti sono RJ45, ma non è ethernet e ci certo non è TCP/IP, non credo siano pubbliche le specifiche. Qualcosa di simile esiste da tempo in ambito pro e lo usa, per esempio, beringher, la siga è AES50, Dante, Ravenna ed anche AVB sono evoluzioni ad un livello di astrazione superiore.

Pertanto, nessuno dei ragionamenti fatti più sopra è applicabile pari pari ad un protocollo proprietario di cui personalmente non so nulla, con ogni probabilità si tratta di trasmissione sincrona. Bisogna poi considerare che in questo caso non si tratta solo di un protocollo, ma di una gestione integrata del "sistema" sorgente/connessione/amplificazione/crossover/diffusori.

[DacPassion]

Quindi il loro streamer che è collegato in rete per essere gestito da tablet o altro come funziona? Ha delle porte Ethernet dedicate alle casse e altre alla connessione di rete?

Edit
Si, ho visto la foto. Ha porte separate.
Secondo voi usano un protocollo proprietario perché tutto quello che fa (perfetta sincronia dell varie vie, funzione DSP e altro) non si poteva fare, con le stesse prestazioni, con il protocollo standard?

[UnixMan]

Secondo voi usano un protocollo proprietario perché tutto quello che fa (perfetta sincronia dell varie vie, funzione DSP e altro) non si poteva fare, con le stesse prestazioni, con il protocollo standard?

con alcuni protocolli standard (ad es. proprio "Ravenna") si sarebbe potuto fare. Ma verosimilmente era molto più semplice fare come hanno fatto...

[marcoc1712]

con alcuni protocolli standard (ad es. proprio "Ravenna") si sarebbe potuto fare. Ma verosimilmente era molto più semplice fare come hanno fatto...

Con Ravenna è possibile farlo usando PTPv2 (nSec di precisione nella sicronizzazzione) il che però rende inutilizzabile la gran parte degli switch e degli apparati di rete, richiedendo - di fatto - la realizzazione di un network dedicato. Senza di quello la precisione di Ravenna è quella del GPS, troppo bassa per realizzare l'allineamento di fase dei diversi canali di un diffusore.

[marcoc1712]

Quindi il loro streamer che è collegato in rete per essere gestito da tablet o altro come funziona? Ha delle porte Ethernet dedicate alle casse e altre alla connessione di rete?

Edit
Si, ho visto la foto. Ha porte separate.
Secondo voi usano un protocollo proprietario perché tutto quello che fa (perfetta sincronia dell varie vie, funzione DSP e altro) non si poteva fare, con le stesse prestazioni, con il protocollo standard?

La parte 'streamer' usa UPNP per connettersi al resto del mondo (sembra abbiano abbandonato open Home), ExactLink è utilizato per connetere i diversi device tra loro in una daisy chain (collegamento seriale).

Il problema della 'perfetta sincronia' in digitale è compleso e bisogna intendersi sul significato.

a. sincronia a livello di sample.

Viene definita così: Estendendo all'infinio in avanti ed indietro la durata delo stream, ci sarà sempre un punto preciso e comune in cui i due stream sono a 'tempo 0'. In altre parole, dato l'inizio comune è possibile individuare un 'delta' di velocità correggendo il quale si ottiene la completa e perfetta sincronia.

Per correggere questo delta ci sono due modi:

a. 'scartare periodicamente un sample nello stream più lento.
b. fare il resample di uno (o di entrambi) i due stream ad un rate comune.

Parliamo di errori nell'ordine del mSec.

b. sincronia a livello di fase.

qui si entra nel contenuto dei campioni che costituiscono il singolo frame. Posto che i sample siano 'sincroni' (es. due canali di uno stream stereo lo sono per definziione) possono esserci delta residui più brevi del periodo massimo rappresentabile da un frame allo specifico sample rate. Questi delta non son rappresentabili se non come variazione di valori assunti dai bytes del campione, cioè vengono trasposti dal dominio del tempo a quello della freaquenza.

Per intervenire a questo livello è necessario operare un DSP (resampling).

Ora, se con stream mulicanale questi delta NON possono essere introdotti nel dominio digitale, usando stream separati gestiti da clock diversi diventa possibile, da qui la necessità di avere meccanismi di sincronizzazione ancora più accurati e precisi, quindi l'origine di Ravenna e simili.

Linn va oltre e promette di correggere, sfruttando questo meccanismo, le differenze di fase (ritardi) dei diversi drivers di un diffusore o dovuti al posizionamento in ambiente, misurando l'errore al punto di ascolto ed applicando la correzione.


Non è una pratica nuova, da diverso tempo esistono i crossover digitali ed il DRC, la 'novità' (almeno in ambito consumer) sta nel separare gli stream mediante un crossover digitale ed inviare digitalmente gli n stream ai diversi drivers degli n canali ad altreattanti DAC remoti, ad estremo ridosso del diffusore, minimizzando così l'effetto della variabilità delle componenti analogiche.

Utilizzando IP (quindi anche Ravenna), la massima precisione raggiungibile è di qualche uSec, quindi anche se in teoria è fattibile si è al limite, mentre con connessioni sincrone che condividono ESATTAMENTE lo stesso clock è - almeno logicamente - più facile ottenerlo, dato che in questo caso la tolleranza è nell'ordine dei pSec.

Ma insieme alle rose ci sono sempre le spine...

NOTA BENE:

Senza nulla togliere al valore dei sistemi Linn, si giustificano SOLO se li usi integralmente per lo scopo per cui sono stati ideati (DSP e DRC).

Questa è sempre la chiave di lettura: sistemi diversi servono a scopi diversi, se lo scopo non è significativo nel contesto di riferimento, allora la soluzione è da scartare, non perchè non sia valida, ma perchè mira a risolvere un non problema introducendone certamente di altri.

Detto questo, io sono da sempre un ammiratore di Linn, quindi non ho dubbi che suonino benissimo, ma il prezzo...

[DacPassion]

Grazie, molto esaustivo!!

Giusto per capire la potenzialità di sistemi più "terrestri"
Se per assurdo io costruissi una coppia di casse attive ed in entrambe le casse integrassi un dac e (ad esempio) un raspberry con squeezelite (uno con il canale L abilitato e l'altro con il canale R abilitato) installato; mettendo in rete i due raspberry se da un server con LMS abilitassi il multiroom su quei due player ne uscirebbe fuori una cosa ascoltabile o sarebbe tutto "sfasato"?

[marcoc1712]

Grazie, molto esaustivo!!

Giusto per capire la potenzialità di sistemi più "terrestri"
Se per assurdo io costruissi una coppia di casse attive ed in entrambe le casse integrassi un dac e (ad esempio) un raspberry con squeezelite (uno con il canale L abilitato e l'altro con il canale R abilitato) installato; mettendo in rete i due raspberry se da un server con LMS abilitassi il multiroom su quei due player ne uscirebbe fuori una cosa ascoltabile o sarebbe tutto "sfasato"?

Lascia perdere. Avresti certamente drift anche significativi ed il meccanismo di sincronizzazione di LMS non è tra i più dolci, il canale più lento verrebbe mutilato di un sample ogni n per ripristinare l'allineamento. Io uso sltuariamente quel meccanismo per le prove a confronto A/B e si sente già.

Senza dubbio questo è al di fuori delle specifiche per cui è stato ideato il multiroom di LMS. Ma per cosa useresti questo sistema? Perchè vuoi arrivare in digitale alle casse? Che distanza devi coprire? Nel caso, non puoi usare SPDIF tra 1 PI e due dac?

I canali di uno stream multicanale costituiscono un 'unicum' temporale all'interno di un 'frame', spezzarlo è fonte certa di problemi. Se non ci sono più che validi motivi per farlo, lo eviterei.

Se leggi i documenti ufficiali e di marketing di Ravenna (compresi quelli della Merging), tra i casi d'uso non è MAI citata la riproduzione sterofonica in ambienti domesici, ci sarà un motivo!

[DacPassion]

Marco, come avevo premesso, era giusto per capire le potenzialità del sistema.
Anche se a dire il vero l'idea mi intriga, avere tutto dentro le casse e avere solo il collegamento Ethernet è affascinante ...ma come sempre "risolvi" 10 problemi e te ne ritrovi 20 alla porta!!

[marcoc1712]

Marco, come avevo premesso, era giusto per capire le potenzialità del sistema.
Anche se a dire il vero l'idea mi intriga, avere tutto dentro le casse e avere solo il collegamento Ethernet è affascinante ...ma come sempre "risolvi" 10 problemi e te ne ritrovi 20 alla porta!!

Credo proprio di si, senza contare che mettere le mie belle lampadine dentro al diffusore sarebbe un bel problema, altro che zero feedback! Scherzi a parte, il problema delle vibrazioni meccaniche non è secondario, a mio avviso.

[hifi25nl]

Esiste anche RAAT, il protocollo proprietario di Roon implementato in sempre più apparecchi.

RAAT uses a TCP control channel for basic/management tasks, but the actual audio stream is transmitted over UDP. We also use UDP packets for clock synchronization and to manage resends of dropped/lost packets. The protocol is completely custom--i.e. it is not an application or adaptation of one of a pre-existing system like RTP/RTSP.
RAAT utilizza un canale di controllo TCP per le attività di base/gestione, ma il flusso audio vero e proprio viene trasmesso tramite UDP. Utilizzano anche pacchetti UDP per la sincronizzazione del clock e per gestire rinvii di pacchetti eliminati/persi. Il protocollo è completamente custom - cioè non si tratta dell'applicazione o dell'adattamento di uno dei sistemi preesistenti come RTP/RTSP.

Da quanto mi risulta sono ancora in alto mare...devono ancora scrivere il driver per la scheda audio virtuale AES67. L'unica opzione per il momento in linux (probabilmente performante) è la scheda audinate a 1700-1800 dollari