Driver AVB per LINUX

[marcoc1712]

I nuovi mac sono nativamente predisposti per Ethernet AVB, anche se si usa un dongle Thunderbolt (ma non USB), mentre alcune schede madri ASUS cominciano a supportarlo, manca ancora un driver 'universale' per Windows, ma ne esistono di proprietari.

Fino a poco fa le schede PCIe costavano circa 800 Euro, ma è oggi disponibile questa scheda Intel: Audio Video Bridging for Time-Sensitive Traffic a 39$. Ovviamente è limitata e non permette di gestire migliaia di stream su milioni di canali, ma per i nostri scopi (STEREO) è sovrabbondante.

Intell dichiara che è disponibile il driver sia per WIN (no XP) che Linux, qualcuno ha avuto modo di verificarlo?

Questa scheda + un cavo cat5e CROSS + https://www.minidsp.com/products/network-audio/avb-dg renderebbero inutile il renderer (o NAA).

In caso di network complessi è disponibile anche lo switch (ma ce ne sono molti altri gà assemblati) e sempre miniDSP propone un DAC 8 canali a 300 USD, ma a mio avviso la component epiù interessante è la scheda OEM, da usarsi come sostituto/complemento della JLSOUND.

Ovviamente non ho idea di come la scheda di conversione sia costruita, quindi potrebbe rivelarsi anche pessima, lato audio, ma se è appena appena decente, con 130 USD si elimina USB dalla catena! Se qualche esperto buttasse un occhio...

AVB è certaente sovrabbondante per i nostri scopi, ma visto che non si trova nulla di analogo a pezzi abbordabili, credo che sia una possibile soluzione. Il protocollo layer 3 è lo stesso di Dante e Ravenna, ma visto che è mirato più al lato 'consumer', possiamo trarne vantaggio senza dover necessariamente pagare per funzionalità di cui non ce ne faremmo nulla. Di sicuro prima o poi qualcuno uscirà con la versione Audiophile, ne sono certo...

Sono molto tentato di lanciarmi nella realizzazione, ma avrei una serie di dubbi pratici da risolvere, il primo dei queli è:

cosa si può ed è meglio usare come 'selettore di ingressi' per un dac che abbia USB, Etherrnet e, perchè no, SPDIF?

Grazie.

[UnixMan]

Intell dichiara che è disponibile il driver sia per WIN (no XP) che Linux, qualcuno ha avuto modo di verificarlo?

No. Però, da una veloce ricerca, escono cose come questa:

https://sourceforge.net/projects/e10...x_igb_avb/1.7/

https://github.com/AVnu/Open-AVB/tree/master/kmod/igb

https://github.com/AVnu/Open-AVB

(considerato che si tratta di roba che è in giro da diverso tempo, non escluderei che le funzionalità sia già stata inclusa direttamente nei kernel recenti).

Non mi è chiaro invece come si gestisca la cosa sul versante "applicativo".

Sono molto tentato di lanciarmi nella realizzazione, ma avrei una serie di dubbi pratici da risolvere, il primo dei queli è:

cosa si può ed è meglio usare come 'selettore di ingressi' per un dac che abbia USB, Etherrnet e, perchè no, SPDIF?

ouch... eviterei, decisamente. Dovresti mettere un selettore a livello del bus I2S, cioè proprio in uno dei punti più "sensibili" e delicati della catena. No way.

[marcoc1712]

No. Però, da una veloce ricerca, escono cose come questa:

https://sourceforge.net/projects/e10...x_igb_avb/1.7/

https://github.com/AVnu/Open-AVB/tree/master/kmod/igb

https://github.com/AVnu/Open-AVB

(considerato che si tratta di roba che è in giro da diverso tempo, non escluderei che le funzionalità sia già stata inclusa direttamente nei kernel recenti).

Non mi è chiaro invece come si gestisca la cosa sul versante "applicativo".


ouch... eviterei, decisamente. Dovresti mettere un selettore a livello del bus I2S, cioè proprio in uno dei punti più "sensibili" e delicati della catena. No way.

Applicativamente è trasparente, compare come una scheda audio 'locale'. qualcosa stile JPLAY, per intenderci.

In merito ai progetti che si trovano in giro (compresi quelli HW) è proprio quello che mi preoccupa, sono in giro da tanto tempo ma pochi se li filano, tutti is aspettno un'esplosione che non arriva. XMOS è ormai alla 3° serie di development kit senza compatibiità con i precedenti (il che è un suicidio), mentre si contano sulle dita di una mano i prodotti 'industriali', tutti in ambito PRO e mirati all'audio multicanale e multistream (come è ovvio e giusto che sia).

Non riesco a valutare se per il mondo PRO AVB è meno 'performante' di Dante o Ravenna o se è solo questione di marketing sbagliato, francamente mi pare che siamo ancora a livello di concetto /realizzazioni pilota, ma nessuno che ch abbia invetsito davvero, se non in settori come la teleconferenza, l'automotive.

I tools per provare a realizzare qualcosa che non costi un rene ci sono, l'impressione è che nessuno voglia fare l'investimento di completare l'opera e renderla disponibile a tutti per paura di finanziare i concorrenti....

Quello che non riesco (perchè sono ovino) a capire è se la parte 'audio' (cioè a valle dell'XMOS) è all'altezza di quanto fa almeno la JLSOUND o no (mi pare ci sia solo 1 clock), alla peggio sono due schede separate, volendo si può completamnete sostituire la seconda, ma bisogna progettarla, realizzarla,...

I2S switch... temevo, ma allora come viene gestito nei DAC 'normali' con più ingressi?

EDIT:

Qualcosa tipo questo? http://www.audiophonics.fr/en/switch...e-p-10559.html

[UnixMan]

Quello che non riesco (perchè sono ovino) a capire è se la parte 'audio' (cioè a valle dell'XMOS) è all'altezza di quanto fa almeno la JLSOUND o no (mi pare ci sia solo 1 clock),

più che quello, il problema temo sia a monte. Se non ho capito male, tutto lo scopo di AVB è legato ai problemi di sincronizzazione. In altre parole, il clock (audio!) non è generato localmente, ma arriva dalla rete!

Se è così, e non sono previste modalità alternative "asincrone"... decisamente AVB non fa proprio al caso nostro.

I2S switch... temevo, ma allora come viene gestito nei DAC 'normali' con più ingressi?

EDIT:

Qualcosa tipo questo? Kit Auto Two-way Audio I2S two I2S in/out one out Switching Module - Audiophonics

esatto. Una sonora schifezza.

[DacPassion]

Ho capito male o supporta massimo 96khz?

[marcoc1712]

Ho capito male o supporta massimo 96khz?

192KHz su 2 canali ma in 'full duplex' (2 Tx e 2 Rx contemporanei) quindi in teoria si potrebbe riprogrammare ed arrivare a 384.

[marcoc1712]

più che quello, il problema temo sia a monte. Se non ho capito male, tutto lo scopo di AVB è legato ai problemi di sincronizzazione. In altre parole, il clock (audio!) non è generato localmente, ma arriva dalla rete!

Ni. Ci sono diverse modalità di utilizzo che comunque prevedono un clock locale che periodicamente si riallinea al 'master' che può essere quello di un qualsiais dispositivo AVB in rete (quindi anche un mater clock esterno collegato ad un dispositivo e quindi 'condiviso'). E' piuttosto il meccanismo usato per i satelliti GPS, più frequente è l'allineamento meno importante è il massimo drift, fino ad un minimo di < 1 uSec, mentre riesce a ridurre la latenza a < 1 msec.

Se è così, e non sono previste modalità alternative "asincrone"... decisamente AVB non fa proprio al caso nostro.

Sai che è quello che sostengo anch'io, tutto l'overhead per mantenere allineati i clock per noi è assolutamente inutile ed alla fine non sono così sicuro che sia 'inudibile', quindi meglio evitare...

Potendo intervenire sui parametri di 'qualità del servizio' e specialmente in una 'rete' composta da un solo 'talker' ed un solo 'listener' dovrebbe essere ininfluente, ma il condizionale è d'obbligo...

esatto. Una sonora schifezza.

Ti ripropongo la domanda: Come viene realizzato nei DAC 'commerciali' con diversi ingressi (SPDIF, TosLink, AES/EBU e USB)? E' (sarebbe) sempre da evitare? ...sono troppe le cose che non so per cimentarmi in questo campo, questo è il grande freno.

[UnixMan]

Ni. Ci sono diverse modalità di utilizzo che comunque prevedono un clock locale che periodicamente si riallinea al 'master' [...] tutto l'overhead per mantenere allineati i clock per noi è assolutamente inutile ed alla fine non sono così sicuro che sia 'inudibile', quindi meglio evitare...

appunto. Anche perché il problema non è tanto quello dell'overhead (probabilmente irrilevante), quanto il fatto che un simile meccanismo (analogo a quello adottato da alcuni "ricevitori" S/PDIF) implica che il clock locale deve essere "controllato"... e questo fa a cazzotti con la minimizzazione di jitter e phase-noise. A quel punto tanto varrebbe tornare proprio all'S/PDIF, implementato al meglio...

Ti ripropongo la domanda: Come viene realizzato nei DAC 'commerciali' con diversi ingressi (SPDIF, TosLink, AES/EBU e USB)?

spesso proprio con un sistema analogo a quello della schedina di cui hai postato il link. In altri casi è la stessa MCU che gestisce i flussi a prevedere ingressi alternativi ed a permettere lo "switch" tra l'uno e l'altro.

E' (sarebbe) sempre da evitare?

In teoria, se il sistema è pensato ed implementato bene, cioè facendo un reclocking sincrono con il clock locale a valle del punto dove avviene la "selezione degli ingressi", la cosa potrebbe/dovrebbe essere ininfluente dal punto di vista del jitter e quindi della qualità del suono. Ma fare una cosa del genere -ben fatta- implica un bel po' di complicazioni (e quindi anche di costi) in più. Ne vale la pena?