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?

[marcoc1712]

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...

Posto che la penso ESATTAMENTE allo stesso modo, motivo per cui mi piacerebbe trovare una soluzione funzionalmente analoga (*) ma in PURO ambito TCP/IP (chissenefrega della latenza!), il punto rimane che per uscire in S/PDIF piuttosto che in USB o I2S, in qualche modo vicino al DAC ci devi arrivare, qindi ti serve 'qualcosa' che faccia da bridge e torniamo al punto di partenza.

Quelle schedine + il NIC Intell hanno il grosso vantaggio di non costare un rene come altre soluzioni Dante/Ravenna ed in più (ma questo è da verificare) il vantaggio di AVB sarebbe che 'attiva' i meccanismi di sincronizzazione solo quando necessario (devi compilare una matrice di talker e listener sincronizzati tra loro, qindi con un solo talker ed un solo listener non c'è nulla da sincronizzare....) tanto che qualcuno riporta che funziona anche con hw non AVB in mezzo, ma torna il mio dubbio sulla qualità della 'sezione' audio, in particolare del(i?) clock.

(*) In realtà si tratta di due approcci completamente diversi al problema. AVB, Dante, Ravenna,... replicano funzionalmente i primi tentativi di utilizzo della rete (AES50 es. beringer) fisica, cioè del cavo cat5e, ma NON IP, dove, in pratica, si gestisce un 'device' remotizzato ma schiavo, 'come se' fosse connesso localmente al player, in altre parole in rete gira AUDIO SINCRONO (con i distinguo del caso).

Nelle nostre applicazioni, invece, TCP/IP trasporta SOLO raw streams (quando non proprio files) che il renderer trasforma localmente ed in modo ASINCRONO in Audio, mediante una sua logica indipendente ed un suo clock (comunque derivato o controllato). Questo è il grande vantaggio se parliamo di riproduzione di un solo stream reso da un solo renderer, che diventa di rimando il grande svantaggio quando è necessario 'sincronizzare' stream/renderer diversi (o l'audio con il video).

Sono applicazioni diverse, anche se certamente proveranno a contrabbandarci AVB o analoghi come la panacea, il mio è solo un tentativo di 'infilarmi nelle pieghe' e sfruttare il mezzo per un fine diverso.

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?

Il problema per me, non sono tanto i costi quanto la capacità di progettarlo e realizzarlo... Era solo per poter confrontare i due diversi ingressi in modo rapido.

[bigtube]

Marco il tuo discorso e il tuo ricercare una soluzione "di rete" con tanta energia secondo me parte da un assunto forse da riconsiderare con attenzione.
Cioe', mi pare ma potrei essermi sbagliato, bisogna" liberarsi a tutti i costi della connessione USB per la trasmissione I2s" .
Io in questi giorni ho varato il mio nuovo DAC che come sai utilizza proprio la connessione USB per tramite della JLSounds.
Addirittura sto connesso al PC nudo e crudo cioè senza alimentatori dedicati sulla JLSounds( e dopo quest'esperienza non so nemmeno se li faro').
La riproduzione nonostante cio' è assolutamente e incredibilmente di qualita' da capogiro.
Questa cosa la dico perchè ho un altro esemplare della stessa scheda che è servita con ottimi alimentatori dedicati per l'altro mio
tradizionale DAC con i 6 chip 1704 e uscita a tubi. Ebbene a onta di tutto cio' affermo con assoluta tranquillita' che il nuovo DAC
batte il vecchio in modo assolutamente evidente. Se ne frega bellamente che ci sia la connessione USB e per giunta direttamente alimentata dal PC.
Percio' è personalmente a me evidente che, ma ne avevo una vaga intuizione altrimenti non mi sarei buttato in questa ultima sperimentazione, la
connessione USB va' benissimo com'è. Quello che conta molto ma molto di piu è come si mette assieme il giochino del DAC. E' su questo aggeggio
che si gioca il gioco vero. L'ho toccato con mano. Ce l'ho davanti alle mie orecchie e al mio cervello. E l'evidenza è drammatica.
Anch'io mi ero fatto pipponi sulle " forche caudine " della connessione USB.....era altro il problema e questa intuizione è diventata consapevolezza.

PS. : Marco forse ricorderai che qualche tempo addietro scrissi che mi sarei dedicato con piu' energia e impegno sul versante
hardware piuttosto che software....ecco appunto...lavorare sulle macchine con buoni progetti puo' costituire un salto...vero.