Protocolli e schede "Audio over IP"

[marcoc1712]

Un certo numero di appassionati mi stanno chiedendo qual è l'attuale situazione riguardo al supporto del protocollo AES67 in Linux (audio di qualità attraverso ethernet invece che USB), vedi
https://en.wikipedia.org/wiki/AES67

Per il momento esistono alcune schede piuttosto costose che supportano anche Linux, la più nota è questa
https://www.audinate.com/products/ma...ante-pcie-card
Four Audio | Dante PCIe Card

Non è disponibile al momento una soluzione software con una "virtual card"

Per una discussione in inglese sul forum del programma di registrazione professionale Ardour, si veda
https://community.ardour.org/node/8833?page=1

Avendo ben chiaro il vantaggio che offrono nel mondo pro ed in particolar modo in sede di gestione del palco, acquisizione e missaggio, mi sfugge il vantaggio che queste soluzioni (in specie basate su DANTE e RAVENNA) possano offrire in sede di riproduzione audio multicanale ma mono stream. Quanto ho visto realizzato fino ad ora divide su strem diversi i diversi canali (o gruppi di canali), il che equivale a crearsi una infinità di problemi del tutto inutili in situazioni domestiche normali. Ovvio che non sto parlando di corse di cavo di 200 mt, ma di 'normali' stanze fino a 50-60 mq.

Perchè AVB (o qualsiasi protocollo basato su AES67) dovrebbe essere preferibile all'IP 'normale' in questi casi?

[hifi25nl]

Una nota: le implementazioni basate su Ravenna e Dante non hanno bisogno di switch dedicati, a differenza di AVB, l'interesse verso il quale è diminuito recentementea a scapito delle soluzioni simili a quella di audinate.
Sembra che il mondo dell'hifi stia per passare armi e bagagli all'"audio over IP", che risolverebbe gran parte dei problemi legati alle uscite USB, aggiundone però probabilmente degli altri.

Un alista dei vantaggi la puoi trovare qui
AUDIO over IP - REDNET 3 & 16 Review. AES67 Sets A New Standard for Computer Audio

Ok what does AES67 and it's current implementations like DANTE and RAVENNA offer:

1- Near zero latency - even over a LAN and long distances
2 - ASIO support and Apple support, as well as Linux. So you can use your current favorite audio player or software.
3 - Full layer 3 TCP/IP support - no special swtiches needed.
4 - Current PC Ethernet port works just fine, or add a PCIe card.
5 - 1 GB massive data throughput
6 - As with all 1GB or higher LAN - native galvanic isolation
7 - No USB gremlins like clocking and Async packet noise or loss

[marcoc1712]

Una nota: le implementazioni basate su Ravenna e Dante non hanno bisogno di switch dedicati, a differenza di AVB, l'interesse verso il quale è diminuito recentementea a scapito delle soluzioni simili a quella di audinate.
Sembra che il mondo dell'hifi stia per passare armi e bagagli all'"audio over IP", che risolverebbe gran parte dei problemi legati alle uscite USB, aggiundone però probabilmente degli altri.

Un alista dei vantaggi la puoi trovare qui
AUDIO over IP - REDNET 3 & 16 Review. AES67 Sets A New Standard for Computer Audio

Ok what does AES67 and it's current implementations like DANTE and RAVENNA offer:

1- Near zero latency - even over a LAN and long distances
2 - ASIO support and Apple support, as well as Linux. So you can use your current favorite audio player or software.
3 - Full layer 3 TCP/IP support - no special swtiches needed.
4 - Current PC Ethernet port works just fine, or add a PCIe card.
5 - 1 GB massive data throughput
6 - As with all 1GB or higher LAN - native galvanic isolation
7 - No USB gremlins like clocking and Async packet noise or loss

E' quello che intendo:

da 2 a 6 sono vantaggi di una architettura IP verso USB, chiari e reali, ma non esclusivi di Ravenna o Dante.

1 è il solo vero vantaggio di queste soluzioni rispetto a TCP/IP 'puro', ma del tutto ininfluente in fase di riproduzione di un solo stream multicanale ove non siano necessarie corse di cavi >> 100 mt. Se poi si usaquesto protocollo 'spezzando' gli stream dei diversi canali cercando la sinconia medaint eil master clock di rete, ci si crea un inutile problema.

7 è opinabile, privilegando la bassa latenza rispetto alla 'certezza', inevitabilmente si creano situazioni in cui un pacchetto mancante viene omesso o, se difettoso, mandato in esecuzione per com'è, pratica validissima e necessaria quando si ha a che fare con stream diversi da sincronizzare e/o in acquisizione, ma PESSIMA (a mio avviso) in riproduzione di un solo stream multicanale, ove la miglior soluzione è certamente un buffer ben dimensionato (che aumenta la latenza), soluzione impraticabile con stram indipendenti.

In realtà - come è avvenuto tra SPDIF e USB - si scambia un male per un altro, scommettendo sul fatto che sia minore, ma - almeno in questo caso - la soluzione è già nel TCP/IP 'standard', da tempo largamente in uso nei network players. La buona notizia è che male (se non ci si mette volutamente in condizioni estreme) non fa, ma ciò che è inutile è dannoso, a mio avviso.

In conclusione, Sia Dante che Ravenna hanno rappresentato un significativo passo avanti rispetto alle soluzioni di livello (in senso architetturale) inferiore, come quelle adottate da Berhinger ed altri, che usano ethernet come layer di comunicazione ma NON TCP/IP ed anche se non è spurtroppo vero che tutti gli apparecchi IP 'standard' siano utilizzabiili all'interno di un network Dante o Ravenna senza problemi, si muovono certamente in quella direzione.

Hanno però un loro uso specifico, che non è quello di essere utilizzati in sale di ascolto domestiche. Poi, per l'amor di Dio, è possibile andare al bar con il Land Rover Defender a passo lungo ed anche con l'autoarticicolato, si incontreranno forse problemi di parcheggio, ma vuoi mettere?

[bibo01]

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.

[bibo01]

Riguardo Ravenna, Mivera sta per fare uscire un apparecchio - Superstream Pro - che contiene una nuova scheda Ravenna che andrà a fare concorrenza alla Merging Technologies.
Non si conosce anora la ditta produttrice, ma qui ci sono alcuni dettagli della sua implementazione:
Mivera Audio Superstream Pro Ravenna

[marcoc1712]

Riguardo Ravenna, Mivera sta per fare uscire un apparecchio - Superstream Pro - che contiene una nuova scheda Ravenna che andrà a fare concorrenza alla Merging Technologies.
Non si conosce anora la ditta produttrice, ma qui ci sono alcuni dettagli della sua implementazione:
Mivera Audio Superstream Pro Ravenna

A volte ho delle premonizioni....

Dalla home page:

This unit will run the incredible Ravenna Audio over IP protocol to convert the audio to the cleanest signal possible

Ravenna converte (?) l'audio al più puro segnale possibile ? Devo chiedere scusa, io ero convinto si trattasse del protocollo Ravenna, non di un ADC...

... e ci troveremo a disquisire di quanto bene faccia Ravenna alle voci maschili, mentre duCulon conferisce peso a quelle femminili.

[marcoc1712]

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.

Se per questo, esiste anche SlimProto nato nel 2001 e base di tutta l'architettura Squeezebox oltre a svariate altre implememntazioni di protocolli proprietari ma sempre basati su TCP/IP (e/o UDP).

Il punto è, perchè nella riproduzione domestica ci si vuole complicare la vita adottando sistemi il cui scopo è quello di 'condividere' un clock al fine di sincornizzare stream diversi e limitare al massimo la latenza. E' uno dei pochi problemi che non abbiamo, perchè 'importarlo'?

[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

[marcoc1712]

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

Perchè parli di AES67 per RAAT? Per quanto ne so io RAAT non è AES67, ma una implememntazione proprietaria su TCP/IP. Mi sfugge qualcosa?