Facciamo il punto sui di versi metodi di interconnessione digitale?

[UnixMan]

Qualcuno ha provato con un PI o ODROID?

sarebbe da provare con un BBB in unione ad una delle interfacce I2S dirette dedicate, con clock esterno:

http://bbb.ieero.com/

https://hifiduino.wordpress.com/2014...ack-for-audio/

(l'interfaccia di TP è attualmente "out of stock"... non vorrei abbiano deciso di abbandonarla).

Ci sono però anche altre soluzioni, tra cui quella di "ACKO":

https://hifiduino.wordpress.com/2015...-developments/

http://www.diyaudio.com/forums/group...ml#post3995427

https://sites.google.com/site/ackodac/home

[marcoc1712]

sarebbe da provare con un BBB in unione ad una delle interfacce I2S dirette dedicate, con clock esterno:

http://bbb.ieero.com/

https://hifiduino.wordpress.com/2014...ack-for-audio/

(l'interfaccia di TP però è attualmente "out of stock"... non vorrei abbiano deciso di abbandonarla).

Ci sono però anche altre soluzioni, tra cui quella di "ACKO":

https://hifiduino.wordpress.com/2015...-developments/

Amanero Isolator/Reclocker GB - Page 109 - diyAudio

TPA mi pare abbia abbandonato l'interfaccia per BBB, anche se non ho capito perchè. (EDIT: mi riferivo ad u ost in un altro tHD, scusa).

Di soluzioni diverse ce ne sono realmente tante, la particolarità di quella del canadese, mi pare, è di NON dipendere in alcun modo dal clock originario, ma di scartarlo proprio e sostituirlo, così che - a suo dire - qualiasi sorgente I2S è analoga, che sia il PI, BBB od un CDPlayer non conta.

Arriva a sostenere che il suo obiettivo è che non siano sonicamente distinguibili a valle del reclocker (a parità di cristalli), che mi pare molto sano.

Come sempe le implementazioni non sono mai identiche, quindi immagino ci siano differenze tra TPA, ACKO ed il canadese, ma io sono ancora molto più indietro e sto cercando di capire COSA fanno le diverse componenti prima di verificare il COME (anche perchè non sono in grado).

Vedo di postare uno schema a blocchi, giusto per capire.

[UnixMan]

TPA mi pare abbia abbandonato l'interfaccia per BBB, anche se non ho capito perchè, ma perchè ritieni che si dovrebbe utilizzare fifo + Recloker INSIEME alla solizuione TPA? non fanno la stessa cosa?

eh? err, no-no, intendevo dire come alternativa!

Di soluzioni diverse ce ne sono realmente tante, la particolarità di quella del canadese,

e mo' chi è questo canadese? mi deve essere sfuggito...

[...] è di NON dipendere in alcun modo dal clock originario, ma di scartarlo proprio e sostituirlo,

in teoria, questo è ciò che fa qualsiasi sistema di reclocking...

così che - a suo dire - qualiasi sorgente I2S è analoga, che sia il PI, BBB od un CDPlayer non conta.

Arriva a sostenere che il suo obiettivo è che non siano sonicamente distinguibili a valle del reclocker (a parità di cristalli), che mi pare molto sano.

Strano non direi proprio: è esattamente quello che dovrebbe essere...

...il problema è riuscire veramente ad ottenere quel risultato. Ci si sono provati in tanti, ma non so se nessuno ci sia mai riuscito davvero.

Come sempe le implementazioni non sono mai identiche, quindi immagino ci siano differenze tra TPA, ACKO ed il canadese, ma io sono ancora molto più indietro e sto cercando di capire COSA fanno le diverse componenti

in linea di principio, la cosa è semplice: il BBB può operare (la sua uscita I2S) in due modi: generando il clock internamente oppure utilizzando un clock esterno. Per quel che ci riguarda ci serve che il BBB utilizzi un opportuno clock esterno (quello "low jitter" del DAC), quindi si tratta di fornirglielo.

Ovviamente le complicazioni sono nei dettagli: bisogna "dire" al BBB di utilizzarlo, gestire lo switch tra i clock per le due frequenze base, interfacciarsi opportunamente con l'OS, fare una eventuale/opportuna rigenerazione del segnale I2S (con reclocking) subito prima di inviarlo al DAC, ecc, ecc.

In fact there would have been no adapter board for BBB like the BBB-DSD if the I2S/DSD switching were done internally within the BBB hardware/software and of course this risk of possible damage to BBB when power is interrupted, requiring additional arrangements as you can see on the board with the uC watchdog/battery

http://www.diyaudio.com/forums/group...ml#post4282545

Foto:
http://www.diyaudio.com/forums/group...ml#post4291485

Foto/report:
http://www.diyaudio.com/forums/group...ml#post4309912

[marcoc1712]

eh? err, no-no, intendevo dire come alternativa!


e mo' chi è questo canadese? mi deve essere sfuggito...

...Cenere in capo...

credevo di aver in precedenza risposto citando il lavoro di questo tipo canadese: Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter - diyAudio, quindi pensavo mi rispondessi di conseguenza... Ho alimentato il caos... chiedo venia.

in teoria, questo è ciò che fa qualsiasi sistema di reclocking...
Strano non direi proprio: è esattamente quello che dovrebbe essere...

capisco che cercando di leggere nei miei errori possa succedere, ma stavolta ho scrito quello che intendevo: sano, non strano...

Come dicevo, le implementazioni sono di certo diverse e di conseguenza anche i risultati, ma io sono ancora allo step di capire se l'obiettivo che si pongono (e quindi le funzioni che implementano) sono le stesse o meno, lasciando stare per un momento DSD che aggiunge complicazioni, dato che prevede l'utilizzo dello stesso cablaggio con significato diverso ed è specifico di ogni singola sorgente.

la mia ignoranza del 'come' è abissale, quindo non riesco bene a capire i diversi ruoli sui diversi flussi:

Immaginado i seguenti step:

1. source
2. FIFO
3. Reclocker
4. DAC

come vengono interessati dai diversi flussi?

a. DATA, questo è il più chiaro, viene ricevuto nel FIFO ed immagazzinato, quindi prelevato nuovamente in modo asincrono al ritmo del nuovo clock.
b. MCLK, anche questo è abbastanza chiaro, viene sostituito integralmente.Però non capisco bene perchè bisognerebbe dire alla sorgente di utilizzarlo (rendendola slave), incappando così nei limiti del RPI.

c. WS (LRCLK)
d. BCLK

Non mi è chiarisimo, ma cambiando il clock ed essendo stato introdotto il delay del FIFO, immagino debbano necessariamente essere risincronizzati dal reclocker.

Gli originari servono per determinare il sample rate (BCLK) ed il bit depth (LRCLK), ma solo per quello? Vengono completamete ricostruiti elettricamente?

In altre parole, la sorgente 'crede' di essere il master (cioè usa il proprio clock), quindi perchè ci si dovrebbe preoccupare del fatto che possa operare in SLAVE mode ricevendo il clock esternamente? Questo è quello che mi sfugge...

Altro dubbio:

I DAC 'nati' per funzionare come 'master' (che cioè hanno il proprio clock) non hanno già qualcosa di simile implementato? Possono essere comunque utilizzati e trarne un qualche giovamento?

Certamente saranno domande gnocche, ma comincio a vedere uno spiraglio di luce...

Però siamo OT, probabilmente è meglio aprire una discussione dedicata...

[UnixMan]

credevo di aver in precedenza risposto citando il lavoro di questo tipo canadese: Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter - diyAudio, quindi pensavo mi rispondessi di conseguenza...

Ah, OK. Mai avuto occasione di provarlo, ma a suo tempo avevo visto (e per un po' seguito) quel topic. :-)

stavolta ho scrito quello che intendevo: sano, non strano...

Ops... sorry. Sono io che purtroppo sono sempre più ciecato...

Come dicevo, le implementazioni sono di certo diverse e di conseguenza anche i risultati, ma io sono ancora allo step di capire se l'obiettivo che si pongono (e quindi le funzioni che implementano) sono le stesse o meno,

Ni.

L'idea di base è sempre la stessa (fornire al DAC uno stream I2S quanto più possibile "pulito" e con il minimo jitter possibile), ma i dettagli cambiano in modo piuttosto sostanziale.

Nel caso di ACKO (e -se non vado errato- anche del "cronus" di TPA) in sostanza si tratta del solito reclocking sincrono: si genera un clock locale quanto migliore possibile; da una parte lo si "manda indietro" alla sorgente digitale in modo che questa lo usi come base dei tempi per il suo stream di uscita (quello in ingresso al reclocker) mentre dall'altra, localmente, si rigenera nel miglior modo possibile il segnale I2S di uscita (che va al DAC) a partire dai dati in ingresso e dal (medesimo) clock locale.

Poiché il master clock è lo stesso, uscita ed ingresso restano sostanzialmente sincroni tra loro (salvo i piccoli scostamenti più o meno casuali dovuti al diverso jitter).

Al contrario, il progetto del canadese (pensato per non essere legato a "sorgenti" specifiche e per altro nato in tempi in cui a farla da padrone era ancora S/PDIF) utilizza una strategia leggermente diversa.

Anche in questo caso si tratta sostanzialmente di reclocking (con rigenerazione del segnale), basato su un clock locale ed indipendente, a basso jitter. Ma, sebbene sia effettuato con l'ausilio di un buffer (FIFO), in questo caso si tratta per così dire di un reclocking... "sbagliato", in quanto in sostanza è un reclocking sincrono applicato senza sincronizzare lo stream di ingresso con quello di uscita (ed in assenza di controlli di flusso).

Questo ovviamente crea un grosso problema: poiché il clock locale che comanda lo stream di uscita è diverso ed indipendente da quello della "sorgente" che comanda lo stream in ingresso al FIFO, in media uno dei due clock potrebbe essere (è, sempre) "leggermente più veloce" o "leggermente più lento" dell'altro.

Dal momento che non esistono (e non possono esistere) meccanismi di controllo di flusso, la ovvia ed inevitabile conseguenza è che, in un dato intervallo di tempo, in ingresso al FIFO possono arrivare più campioni di quanti non ne siano stati inviati al DAC nel medesimo intervallo di tempo, o viceversa che in uscita verso il DAC debbano essere (vengano) inviati più dati di quanti non ne siano arrivati in ingresso.

In altre parole, "periodicamente" il buffer si riempie completamente e "trabocca" oppure si svuota del tutto. Si verifica cioè un overrun, che fa sì che un campione in ingresso debba essere scartato, oppure si verifica un underrun, e quindi nello stream di uscita deve essere inserito un campione "fasullo" (tipicamente viene ripetuto quello precedente).

Tenuto conto del fatto che tipicamente i clock in questione hanno frequenze molto precise (quindi vicine) ed una discreta stabilità (quindi "drift" contenuti), l'uso di un buffer di dimensioni generose fa sì che tali errori si verifichino ad intervalli di tempo relativamente ampi.

Questo, unito alle caratteristiche del segnale audio digitale (ed ai successivi filtraggi che avvengono nel DAC, nonché alle caratteristiche della percezione umana), fa sì che gli errori che così facendo si vengono inevitabilmente a creare risultino (dovrebbero risultare) sostanzialmente inaudibili.

Di fatto però quell'oggetto non può essere considerato "bit perfect", in quanto introduce una error-rate tutt'altro che trascurabile.

Così non è invece nel caso del reclocker di ACKO, ed in generale in tutti quei sistemi che consentono di sincronizzare "la sorgente" al clock utilizzato dal reclocker. Essendo gli stream sincroni, in quel caso non il problema non si pone: tutto procede allo stesso "ritmo" e non si possono verificare né overrun né underrun.

(non per caso per effettuare un reclocking sincrono non è necessario utilizzare un vero e proprio buffer: ad es. basta un banale flip-flop. Che per altro può anche essere visto come un buffer FIFO... da 1bit).

b. MCLK, anche questo è abbastanza chiaro, viene sostituito integralmente.Però non capisco bene perchè bisognerebbe dire alla sorgente di utilizzarlo (rendendola slave), incappando così nei limiti del RPI.

proprio per la necessità di sincronizzare i due flussi, per evitare underrun / overrun...

Gli originari servono per determinare il sample rate (BCLK) ed il bit depth (LRCLK), ma solo per quello? Vengono completamete ricostruiti elettricamente?

sì. In tutti i casi i segnali del bus I2S di uscita sono completamente (ri)generati localmente.

In altre parole, la sorgente 'crede' di essere il master (cioè usa il proprio clock), quindi perchè ci si dovrebbe preoccupare del fatto che possa operare in SLAVE mode ricevendo il clock esternamente? Questo è quello che mi sfugge...

ditto: la velocità di trasferimento è fissa (stream sincroni) e non c'è controllo di flusso, ergo i due stream devono essere sincronizzati.

Altro dubbio:

I DAC 'nati' per funzionare come 'master' (che cioè hanno il proprio clock) non hanno già qualcosa di simile implementato?

di solito usano una qualche forma di ASRC ( asynchronous resampling/reclocking). Che, sebbene non esca mai dal "dominio digitale", sfortunatamente è un processo analogo a quello che avviene in un ADC o in un DAC... e perciò "converte" gli errori (le differenze) tra le due diverse basi dei tempi (jitter e drift) in errori nei dati (valore dei campioni).

Però siamo OT, probabilmente è meglio aprire una discussione dedicata...

in effetti questa discussione sarebbe da spostare in un topic più appropriato... volendo anche questo, dove avevamo già parlato di argomenti affini...