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

[marcoc1712]

Abbiamo approciato il punto più volte:

http://www.nexthardware.com/forum/pc...tml#post944308
http://www.nexthardware.com/forum/pc...tml#post968921

e certamente anche in molte altre occasioni, ma - almeno a me - alcuni aspetti rimangono oscuri, mentre a competenza di Paolo/Unixman (e certamente di altri nel forum) potrebbe permetterci di costituire una base dcomune di conoscenze minime che possa consentire non certo di progettare (e nel mio caso nemmeno di assemblare) soluzioni, ma quantomeno di capire meglio i termini della questione.

Grazie a Paolo ed alle sue chiarissime risposte ho finalmente capito qual'è il vero problema che porta a scartare il Rasperry PI (e la maggioranza di altri SOB) e preferire il Beagle Bone Black ad uso audio:

Solo quest'ultima 'ammette' di ricevere il master clock dall'esterno, così da potersi 'sincronizzare' al DAC, in tutti gli altri casi si realizza un collegamento 'Asincrono' e questo - in tempi più o meno lunghi - porta inevitabilmente a problemi di XRUN.

Oltre a questo, come per tutti i collegamenti asincroni (compreso USB/I2S), si ha un cambio - pur minimo - di frequenza e di conseguenza una variazione del 'significato' dei bit (che rimangono gli stessi) per il DAC. Gli stessi bit interpredati a frequenza maggiore producono un pitch più alto e viceversa.

Dopo questo breve riassunto di quanto ho capito fino ad ora, passo a nuove domande sperando che Paolo non perda la pazienza e continui a fornire le risposte:

a. Il canadese dice in effetti la stessa cosa qui, mentre lo schema allegato subodora la presenza di un qualche meccanismo di controllo (asincrono) del flusso, che però temo si limiti a quello che evidenzi tu: in caso di underrun produrrà un buco (o ripete il campione) in caso di overflow scarterà un campione (o più).

Concettualmente è un punto criitico, ma considerando un dirft tra i due clock di qualche decina (diciamo 100, condizione abnorme) di ppm, un buffer di 8 Mbit che inizi a trasmettere alla condizione di 'mezzo pieno' con stream a 44100/16 andrà in condizione di errore dopo circa 135 ORE di funzionamento, a 384/32 8 Ore.

EDIT: qui viene spiegato come viene ripristinato il livello del Fifo sfruttando i periodi di silenzio.

b. Parli di Resampling asincrono, ma in questo caso non mi pare che si abbia un vero e proprio resampling con ricostruzione dello stream di dati, quello che avviene è che cambia il 'pitch', cioè il come la serie di bit (uguale a se stessa) verrà interpretata dal DAC in ragione del nuovo clock, producendo certamente una diversa forma d'onda analogica, ma rimanendo pur sempre 'bit perfect', no?

Ancora una volta non mi pare diverso da quanto avviene con USB, al netto del fatto che lo stream in USB viaggia a velocità talmente superiori da scongiurare l'underrun, mentre il meccanismo di controllo insito in USB consente di 'mettere in pausa' il trasferimento quando il buffer è 'mezzo pieno' per riprenderlo non appena scende sotto tale livello.

c. (ovviamente ha senso solo se ho capito bene A e B) A parità dei cristali, c'è un vantaggio REALE nell'averlo nelle immediate vicinanze del DAC chip e quindi usarlo come master rendendo 'schiavo' il fifo (o l'interfaccia USB)?

d. Se c, avrebbe senso costruire tutto questo 'nel' dac (o almeno sulla stessa scheda) ? Nel qual caso qualsiasi soluzione DIY risulterebbe penalizzata rispetto a network players integrati come lo SB? In che misura?

Grazie.

[UnixMan]

[...]ho finalmente capito qual'è il vero problema che porta a scartare il Rasperry PI (e la maggioranza di altri SOB) e preferire il Beagle Bone Black ad uso audio:

Solo quest'ultima 'ammette' di ricevere il master clock dall'esterno, così da potersi 'sincronizzare' al DAC,

esatto.

in tutti gli altri casi si realizza un collegamento 'Asincrono' e questo - in tempi più o meno lunghi - porta inevitabilmente a problemi di XRUN.

non necessariamente. Anzi, in effetti, salvo forse qualche rara eccezione (ad es. chi usi il FIFO di Ian) di solito non funziona affatto così: nella maggior parte dei casi il collegamento è sincrono... con il master clock che è fornito (fino al DAC) direttamente dal SOB.

Il che ovviamente non è una gran bella cosa, per vari motivi:

*) Il clock del SOB, i circuiti che lo trattano e le relative alimentazioni non sono certo pensati per usi audio, quindi non sono ottimizzati per avere elevata precisione e stabilità con basso jitter / phase noise.

*) il clock di sistema è unico, e tipicamente ha una frequenza che non ha nulla a che vedere con quelle necessarie agli stream audio; pertanto, il clock "audio" dell'uscita I2S deve essere "sintetizzato" a partire da quello. Cosa che ne peggiora ulteriormente la "qualità" (e talvolta limita anche i sample-rate audio che è possibile supportare).

Per cercare di ovviare ad alcuni di questi problemi spesso si ricorre al “reclocking asincrono”, che in realtà non è altro che una applicazione delle tecniche di (A)ASRC (Arbitrary Asynchronous Sample-rate Conversion), cioè di resampling (ricampionamento) nel dominio digitale. Che in pratica è un processo analogo ad una doppia conversione D/A->A/D (salvo che si resta sempre nel dominio digitale).

L'utilizzo di un ASRC permette di "disaccoppiare" i due clock, producendo uno stream di uscita controllato da un clock locale indipendente e perciò (potenzialmente) a basso jitter. Ma, sfortunatamente, si tratta di una soluzione tutt'altro che "perfetta": sebbene infatti di solito gli ASRC abbiano una certa capacità di "reiezione" del jitter in ingresso, gli effetti di questo vengono sempre (almeno in parte) irrimediabilmente "inglobati" nel valore dei campioni in uscita (che sono sempre diversi da quelli in ingresso).

Ecco quindi che l'unica vera soluzione possibile è quella di utilizzare esclusivamente link asincroni e/o, ove ciò non sia possibile, rendere la sorgente "slave" (sincrona) rispetto ad un master clock audio di qualità adeguata, posizionato quanto più vicino possibile al DAC.

Oltre a questo, come per tutti i collegamenti asincroni (compreso USB/I2S), si ha un cambio - pur minimo - di frequenza e di conseguenza una variazione del 'significato' dei bit (che rimangono gli stessi) per il DAC. Gli stessi bit interpredati a frequenza maggiore producono un pitch più alto e viceversa.

???

Qui non ti seguo. O meglio capisco (in parte) cosa vuoi dire ma, detto così, mi pare irrilevante/fuorviante.

Per fare chiarezza, ripartiamo dal principio.

Un segnale audio porta con sé due diverse informazioni: quella temporale e quella relativa all'ampiezza istantanea corrispondente a ciascun istante di tempo.

In un qualsiasi sistema di registrazione e riproduzione (sia analogico che digitale) queste due informazioni vengono (necessariamente) separate tra loro.

Da una parte, l'informazione relativa alle ampiezze viene immagazzinata (registrata) in qualche modo sotto forma di una sequenza (continua=analogico oppure discreta=digitale) immutabile (auspicabilmente tale) di "valori" proporzionali alle ampiezze assunte dal segnale originale (livello di magnetizzazione di un supporto magnetico, scostamento della posizione della parete di un solco rispetto ad una spirale in un disco meccanico, valore numerico dei campioni in un sistema digitale, ecc).

Dall'altra, l'informazione temporale viene invece affidata ad una "base dei tempi" di riferimento prefissata che (in teoria, auspicabilmente) è nota e riproducibile.

L'informazione temporale quindi non viene "registrata" ed immagazzinata ma al contrario viene "scartata" in fase di registrazione e successivamente "ricreata" artificialmente in fase di riproduzione, sfruttando una informazione "a priori": quella relativa alla conoscenza della base dei tempi che è stata utilizzata in fase di registrazione (velocità di trascinamento del nastro, "sample-rate" dello stream digitale, ecc).

Se l'informazione (registrata) relativa alle ampiezze è esatta ed inalterata e la base dei tempi utilizzata in fase di riproduzione è perfettamente identica a quella utilizzata in fase di registrazione, il segnale riprodotto è perfettamente identico a quello originale.

(ovviamente salvo che per la differenza -costante- di tempo assoluto tra registrazione e riproduzione, che è proprio ciò che si vuole ottenere).

Con le moderne tecniche digitali siamo in grado di quantificare con notevole precisione i valori relativi alle ampiezze e di garantire che questi vengano immagazzinati e trasferiti senza alcun errore. Qualche problema in più invece continuiamo ad averlo con la base dei tempi, cioè il famoso "clock": è fisicamente impossibile garantire che quello utilizzato dal DAC in fase di riproduzione sia perfettamente identico a quello utilizzato dall'ADC in fase di registrazione. Per quanto piccole, ci saranno sempre ed inevitabilmente delle differenze (inconoscibili ed incontrollabili) nei tempi (relativi) in cui un dato campione è stato acquisito dall'ADC rispetto a quando questo viene riconvertito dal DAC.

Così come disponendo di un nastro magnetico non abbiamo alcun modo di sapere (istante per istante) quale fosse la reale, effettiva velocità di trascinamento del nastro durante la registrazione, ma al più ne conosciamo solo il valore nominale (teorico, supposto perfettamente costante), allo stesso modo disponendo di una sequenza di campioni non abbiamo alcun modo di sapere quale fosse l'effettiva, reale sequenza di istanti in cui tali campioni sono stati acquisiti dall'ADC (cioè l'esatta sequenza temporale del relativo clock). Al più conosciamo solo il sample-rate, cioè la frequenza di campionamento, "nominale".

Tutto ciò che possiamo fare, in un caso come nell'altro, è cercare di aderire quanto più possibile alla condizione ideale. Cioè, nel caso del nastro, garantire una velocità di trascinamento quanto più possibile uniforme e pari a quella nominale. Idem nel caso del sistema digitale: l'obbiettivo è fornire un clock quanto più possibile stabile, privo di jitter e con frequenza pari a quella nominale.

( in entrambi i casi sperando che anche in fase di registrazione sia stato fatto altrettanto... )

In pratica, il migliore clock di cui possiamo (convenientemente) disporre è un oscillatore al quarzo opportunamente ottimizzato per lo scopo. Ma non basta: questo deve essere posto quanto più possibile fisicamente vicino al punto in cui viene utilizzato, cioè al chip del DAC (o dell'ADC). Questo perché qualsiasi collegamento elettrico degrada inevitabilmente il segnale -analogico- che trasporta l'informazione di clock. Causando un aumento del jitter in misura tanto maggiore quanto maggiore è la distanza tra l'oscillatore e l'utilizzatore.

Tutto questo lungo (nonché trito e ritrito...) discorso introduttivo mira a chiarire e ribadire un concetto tanto semplice quanto fondamentale:

così come in un sistema di registrazione e riproduzione basato su nastro magnetico (analogico) contano solo le differenze (medie e momentanee) tra la velocità di trascinamento del nastro al momento della registrazione e quella al momento della riproduzione (mentre ad es. la velocità con il quale il nastro viene riavvolto sulla bobina prima della riproduzione è irrilevante), così in un sistema digitale contano soltanto le differenze (medie e/o mementanee) tra il clock utilizzato in origine dall'ADC e quello impiegato dal DAC alla fine della catena.

Tutti gli altri clock, cioè quelli utilizzati per scrivere, rileggere e trasferire i dati da una parte all'altra, ecc, sono del tutto irrilevanti... salvo in due casi:

1) i clock coinvolti in qualsiasi eventuale operazione intermedia che in qualche modo "ricombina" l'informazione temporale con i dati, producendo una nuova e diversa sequenza di dati: è ad es. il caso di eventuali "doppie conversioni" D-A-D intermedie, degli ASRC, ecc.;

2) laddove il clock "critico" (cioè quello che comanda il DAC o l'ADC), sia in qualche modo influenzato/controllato da altri clock. Ad es. in presenza di link sincroni laddove il "master clock" è dalla parte opposta del link rispetto al DAC o all'ADC.

Quest'ultimo è ad es. il caso dei vecchi S/PDIF ed AES/EBU (nonché dei corrispondenti ottici Toslink e Adat), quando utilizzati tra "sorgente digitale" e DAC.

Ma, in un certo senso, (spesso) è anche il caso del bus I2S che comanda il DAC, quando questo non è confinato (insieme al clock) in un piccolo spazio nei dintorni del DAC chip medesimo.

Dopo tutta questa lunga (e forse inutile) tirata, mi riallaccio ( finalmente... ) a quanto dicevi: sì, un link asincrono porta ad utilizzare un clock diverso e perciò in effetti può cambiare (cambia) leggermente anche "il pitch" del segnale audio ricostruito. Ma... rispetto a cosa?

Evidentemente, rispetto a quello che sarebbe prodotto da un altro clock diverso. Che però (almeno quando si ha a che fare con una riproduzione in tempo differito) non è (e non può essere) “quello originale”.

Perciò, diversamente da quanto si potrebbe (fra)intendere da quanto scrivevi, l'uso di link asincroni non crea una (nuova) "alterazione" del segnale, ma semplicemente un risultato diverso da quello che sarebbe prodotto da un (qualsiasi) altro clock.

Poiché inoltre l'uso di un link asincrono consente di "avvicinare" quanto più possibile il (master) clock al DAC, ciò rende possibile ottenere un miglioramento della "qualità" del relativo segnale e quindi (potenzialmente, a parità di altre cose) può portare a migliorare la qualità della riproduzione rispetto a soluzioni in cui il clock è (materialmente e/o elettricamente) più lontano dal DAC.

a. Il canadese dice in effetti la stessa cosa qui, mentre lo schema allegato subodora la presenza di un qualche meccanismo di controllo (asincrono) del flusso, che però temo si limiti a quello che evidenzi tu: in caso di underrun produrrà un buco (o ripete il campione) in caso di overflow scarterà un campione (o più).

Concettualmente è un punto criitico, ma considerando un dirft tra i due clock di qualche decina (diciamo 100, condizione abnorme) di ppm, un buffer di 8 Mbit che inizi a trasmettere alla condizione di 'mezzo pieno' con stream a 44100/16 andrà in condizione di errore dopo circa 135 ORE di funzionamento, a 384/32 8 Ore.

Mmmh. Se così fosse, l'error-rate sarebbe decisamente irrilevante. Non ricordo più i dettagli, ma a naso mi sembra una stima ottimistica. In ogni caso, in pratica all'ascolto sarebbe sostanzialmente irrilevante anche se fosse enormemente peggio di così, diciamo nell'ordine di un errore (singolo campione "saltato" o ripetuto) ogni qualche decina di secondi, ovvero due/tre errori per traccia o giù di lì...

BTW: non ricordo quale sia la dimensione del buffer utilizzato in quel progetto, ma vedo un problema: evidentemente, tanto più grande è un buffer tanto maggiore è il tempo necessario a riempirlo (sia pure parzialmente) prima di iniziare la riproduzione, cioè la latenza. Per giunta, poiché (a differenza di quanto accade ad es. con il "bufferone" di squeezelite) il trasferimento dei dati in ingresso avviene "in tempo reale", per immagazzinare nel buffer 1s di dati occorre (inevitabilmente) un secondo di tempo... il che implica che a buffer molto grandi corrisponderebbero latenze inaccettabili.

Per caso hai visto se/come è stato affrontato/risolto (se è stato risolto) questo problema?

EDIT: qui viene spiegato come viene ripristinato il livello del Fifo sfruttando i periodi di silenzio.

interessante. Grazie per la segnalazione.

b. Parli di Resampling asincrono, ma in questo caso non mi pare che si abbia un vero e proprio resampling con ricostruzione dello stream di dati, [...] rimanendo pur sempre 'bit perfect', no?

se ti riferisci ancora al FIFO di Ian no, nulla a che vedere con il resampling asincrono (ASRC). In questo caso, fatti salvi i casi di XRUN (laddove ci sono campioni mancanti o ripetuti) i campioni in uscita restano uguali a quelli in ingresso.

Dicevo che (a rigore) non può considerarsi "bit-perfect" solo in virtù del fatto che si è in presenza di una "error-rate" che, per quanto (presumibilmente) mantenuto entro livelli trascurabili agli effetti pratici, non è trascurabile da un punto di vista "tecnico/informatico": se registro lo stream in uscita per un tempo sufficientemente lungo, gli errori (XRUN) inevitabilmente presenti fanno sì che questo non è identico a quello in ingresso, ergo si viola la definizione di "bit-perfect".

Ancora una volta non mi pare diverso da quanto avviene con USB, al netto del fatto [...]

in un certo senso, sì.

Ovviamente da un punto di vista tecnico/logico e nei dettagli le differenze sono numerose e sostanziali ma, da un punto di vista pratico, fatti salvi gli errori (e posto che siano effettivamente insignificanti) il risultato finale è sostanzialmente il medesimo: trasferire i dati al DAC secondo il ritmo di un clock locale, in modo indipendente da qualsiasi altro clock "upstream".

c. (ovviamente ha senso solo se ho capito bene A e B) A parità dei cristali, c'è un vantaggio REALE nell'averlo nelle immediate vicinanze del DAC chip e quindi usarlo come master rendendo 'schiavo' il fifo (o l'interfaccia USB)?

sì. Il motivo è descritto nella lunga tirata precedente: il clock è un segnale analogico, per giunta estremamente "delicato" in virtù delle sue caratteristiche, ed è perciò soggetto a "deterioramento" ogni volta che lo si trasmette da un punto A ad un punto B. Sebbene tanto quantitativamente quanto qualitativamente la cosa dipenda anche da un gran numero di altri fattori diversi (ad es. a seconda che si usino o meno linee di trasmissione ad impedenza costante, propriamente terminate e con banda passante adeguata, ecc), in generale non è sbagliato affermare che (a parità di altre cose) il segnale di clock si degrada in misura tanto maggiore quanto maggiore è la distanza tra A e B.

d. Se c, avrebbe senso costruire tutto questo 'nel' dac (o almeno sulla stessa scheda) ?

eccome. Non per caso è quanto avviene ad es. nei DAC "Audio Widget" e Mirand, così come in molti altri prodotti ben progettati e curati da questo punto di vista.

Nel qual caso qualsiasi soluzione DIY risulterebbe penalizzata rispetto a network players integrati come lo SB?

Ni. Almeno in linea di principio, nulla vieta di fare altrettanto anche in un oggetto DIY...

In che misura?

bella domanda... difficile dirlo. Specie dal punto di vista di ciò che ci interessa (SQ).

[marcoc1712]

a. SOB Master.

Lo avevo trascurato a priori come di qualità inacettabile, ma in teoria praticabile, grazie per averlo chiarito.


b. Collegamento asincrono / diverso 'pitch'.

Hai capito perfettamente, intendevo esattamente la stessa cosa:

Qualsiasi trasferimento asincrono di informazioni (compresa la partitura scritta) comprense solo INDICAZIONI sul tempo da utilizzare in fase di riproduzione/esecuzione, che vengono interpretate al fine di ricostruire il segnale musicale completo, ma quello che più conta è la 'coerenza' cioè che per tutte le parti riprodotte il tempo sia 'lo stesso' (un po come non conta se il diapason vibra esattamente a 440 Hz, ciò che conta è che TUTTA l'orchestra sia 'accordata' sulla stessa frequenza.

Non è possibile - per definizione - un collegamento 'sincrono' con l'evento registrato, quindi, la miglior approssimazione si ottiene quando sia in fase di registrazione che in fase di riproduzione si cerca il rispetto dello 'standard' convenuto.

E qui potremmo speculare un bel po, ma lo eviterei in questa sede.

Avevo introdotto questo aspetto pèer differenziarlo rispetto a quanto tu definivi non 'bit perfect', cosa che hai chiarito meglio ed in questo senso condivido.

c. XRUN

Come lui steso riporta , Nel FIFO del canadese ci sono 4 Mb di SRAM cioè "0.743 seconds (for 44.1 KHz Fs)" di latenza e "1486 seconds (at 44.1KHz input I2S stream with 500ppm frequency tolerance".

E' vero che si aggiunge latenza, ma 1 secondo di latenza consente 1/precisione in PPM * 1M secondi di 'sicurezza'. Il punto però è che questo vale per evitare che si presenti il problema, ma arrivati al primo XRUN (esaurito quindi il buffer) gli errori avvengono continuamente, quindi non è corretto dire che la frequenz adi errore è di 1 ogni x ore, ma che il sistema è privo di errori per almeno X ore, dopo di che va resettato.

lo sfruttamento dei silenzi tra le tracce consente di 'resettare' il buffer a mezzo pieno, il limite si riferisce, quindi, alla lunghezza massima tra due pause (traccia) non allo stream nel suo insieme.

Convengo sia un 'truccaccio', ma se la velocità dei due segmenti di linea è la stessa (o molto simile) e non si possono attuare meccanismi di controllo è inevitabile. Credo sia lo stesso con S/PDIF o altri, non resco a capire come un ASRC possa evitar equesto tipo di problemi, cosa mi sfugge?

d. DIY

Intendevo con le opzioni presenti, c'è qualcosa fatto così? O magari un dac con già isolatore e reckloker, così da poter collegare qualsiaisi fonte I2S indipendentemente dall'origine del suo clock?

e. la misura...

Ingenuità mia, questo è un aspetto che non si potrà mai definire a priori e nemmeno valutare 'oggettivamente' a posteriori. Un po come come cercare di capire quanto una nuova collezione di capi d'abbigliamento venderà in funzione della qualità dei tessuti utilizzata....

Conta, ma non è certo il primo parametro che ne esprime la 'qualità' (o gradimento).

[marcoc1712]

eccome. Non per caso è quanto avviene ad es. nei DAC "Audio Widget" e Mirand, così come in molti altri prodotti ben progettati e curati da questo punto di vista.

Ma questi hanno USB come input, o mi sfugge qualcosa?

[UnixMan]

a. SOB Master.

Lo avevo trascurato a priori come di qualità inacettabile, ma in teoria praticabile, grazie per averlo chiarito.

IIRC, nella discussione precedente (che hai linkato nel primo post) qualcuno dei forumer (non ricordo più chi, sorry) raccontava di aver utilizzato (proprio in quel modo) un Raspberry Pi e di essere estremamente soddisfatto dei risultati... talvolta anche ciò che in teoria appare inaccettabile, in pratica può rivelarsi meglio di quanto ci si aspetti.

E' vero che si aggiunge latenza, ma 1 secondo di latenza consente 1/precisione in PPM * 1M secondi di 'sicurezza'. Il punto però è che questo vale per evitare che si presenti il problema, ma arrivati al primo XRUN (esaurito quindi il buffer) gli errori avvengono continuamente, quindi non è corretto dire che la frequenz adi errore è di 1 ogni x ore, ma che il sistema è privo di errori per almeno X ore, dopo di che va resettato.

lo sfruttamento dei silenzi tra le tracce consente di 'resettare' il buffer a mezzo pieno, il limite si riferisce, quindi, alla lunghezza massima tra due pause (traccia) non allo stream nel suo insieme.

giusto.

Il problema si pone quando per molto tempo non ci sono pause tra un brano e l'altro, come talvolta capita, e soprattutto con materiali ad alta risoluzione e/o quando si utilizza l'upsampling verso s/r molto alti (come ad es. nel mio caso, 768K/32bit!).

Convengo sia un 'truccaccio', ma se la velocità dei due segmenti di linea è la stessa (o molto simile) e non si possono attuare meccanismi di controllo è inevitabile. Credo sia lo stesso con S/PDIF o altri,

esatto.

non resco a capire come un ASRC possa evitar equesto tipo di problemi, cosa mi sfugge?

come accennavo, in sostanza le tecniche di ASRC utilizzate per questi scopi sono praticamente equivalenti ad una doppia conversione D/A-A/D.

Lo stream in ingresso viene elaborato in modo simile a quanto avviene in un DAC (pur non arrivando fino alla conversione finale), utilizzando il clock "di ingresso", e poi ricampionato (più o meno come se fosse un segnale analogico) utilizzando a tal fine il clock "di uscita".

È proprio per questo motivo che utilizzando tali tecniche il jitter presente in ingresso viene per così dire "convertito" (irrimediabilmente) in "errori" (imprecisione) nei dati di uscita... proprio come se si fosse fatta una doppia conversione passando per l'analogico.

d. DIY

Intendevo con le opzioni presenti, c'è qualcosa fatto così?

mmh, se intendi qualcosa di fatto esattamente così, "all in one" e basato su un SBC/SOC... no, per quanto ne so per ora purtroppo non ce ne sono.

O magari un dac con già isolatore e reckloker, così da poter collegare qualsiaisi fonte I2S indipendentemente dall'origine del suo clock?

idem.

Però, accoppiando una delle soluzioni citate (ACKO, TPA, Ian) ad una scheda DAC tipo quelle che uso io (o quella che è nel tuo "criaturo"), con un minimo di accortezza nel layout generale ci si potrebbe andare abbastanza vicino.

Ma questi hanno USB come input, o mi sfugge qualcosa?

ah... sì, certo. Visto che si parlava in generale non avevo capito ti riferissi espressamente a soluzioni diversa da USB.