Facciamo il punto sui di versi metodi di interconnessione digitale?

[marcoc1712]

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.

Ok,

Si, viene applicata la 'proprietà transitiva': DATA1 e CLK1 = waveform = DATA2 + CLK2, nei limiti di approsimazione del formato utilizzato (introducendo quindi errore), ma in che modo questo elimina i problemi di XRUN?

Non introduce nessun meccanismo di controllo di flusso, quindi dopo X tempo - esattamente come prima - il buffer andrà in underrun o overflow.

Non capisco.

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.

Eccoci al punto, forse.

Nel DAC che ho io è presente un circuito di isolamento (un fifo ad 1 bit) e di reclock, che avviene sulla base del master clock ESTERNO. Immagino sia lo stesso anche nel tuo, il punto è che è un reclock SINCRONO rispetto al trasporto (la JLSOUND nel mio caso) che è il master, mentre il dac è lo slave.

Usando dac come il mio o il tuo a valle di qualcosa come TPA o IAN o ACKO (definiamolo 'accrocchio') si fanno 2 isolamenti e reclcocking in rapida successione, usando lo stesso clock, se si usa la BBB con TPA si rende 'sincrono' anche quel collegamento, scongiurando i problemi di XRUN.

Sia con l'interfaccia USB/I2s che con l'accrocchio, si raggiunge l'obiettivo di portare all'ingresso del DAC chip un segnale I2s sincrono rispetto ad un unico MCLK, 'ripulito' tramite l'isolatore e risincronizzato immediatamente a monte del dac.

Quello che non riesco a valutare è:

a. con l'accrocchio si hanno due isolamenti e reclocking in cascata, è utile, ininfluente o dannoso?
b. non sarebbe meglio - in termini assoluti - usare un clock posto nelle immediate vicinanze del dac chip rendendo il dac MASTER ed il trasporto (accrocchio e/o interfaccia) slave?

Comunque sia grazie, questa chiacchierata mi è stata molto utile per chiarirmi le idee.

[UnixMan]

Si, viene applicata la 'proprietà transitiva': DATA1 e CLK1 = waveform = DATA2 + CLK2, nei limiti di approsimazione del formato utilizzato (introducendo quindi errore), ma in che modo questo elimina i problemi di XRUN?

perché il problema non si pone proprio. Come detto, il procedimento è equivalente ad una doppia conversione DA-AD. Se converti in analogico con un DAC e poi riconverti in digitale con un ADC, puoi forse andare incontro a problemi di XRUN, anche se i clock di DAC ed ADC sono diversi?

Lo stesso vale per l'ASRC. A prescindere dalle differenze tra i clock, lo stream in ingresso rappresenta un segnale continuo, e questo viene ricampionato (utilizzando il clock di uscita). In sostanza l'ASRC calcola il valore assunto dal segnale analogico rappresentato dallo stream di ingresso nel punto corrispondente a ciascun campione di uscita (cioè in corrispondenza ad ogni "colpo di clock", del clock di uscita), ed assegna tale valore al campione stesso. Poiché lo stream di ingresso rappresenta un segnale continuo, non esiste un punto (istante di tempo) in cui il suo valore non sia calcolabile. Anche se tutto viene effettuato tramite calcoli numerici, è esattamente come (ri)passare per l'analogico...

Eccoci al punto, forse.

Nel DAC che ho io è presente un circuito di isolamento (un fifo ad 1 bit) e di reclock, che avviene sulla base del master clock ESTERNO.

che intendi con "esterno"!? c'è un solo master clock, che è quello locale. Anziché essere montato sulla scheda del DAC è montato su quella dell'interfaccia USB/I2S (dal lato "pulito", a valle dell'isolamento galvanico presente sulla stessa), e da li viene inviato al DAC insieme ai dati (ma su una linea dedicata) attraverso il bus I2S.

Per quanto detto, se vogliamo questo è un difetto: sarebbe stato meglio montare il clock (i clock: sono due, per le due diverse basi...) direttamente sulla scheda del DAC, quanto più possibile vicino al chip. Però, da un punto di vista logico/funzionale, non cambia nulla. Si ha solo un leggero peggioramento della qualità del segnale (e quindi un aumento del jitter) a causa della trasmissione su una distanza (relativamente) più lunga.

Immagino sia lo stesso anche nel tuo, il punto è che è un reclock SINCRONO rispetto al trasporto (la JLSOUND nel mio caso) che è il master, mentre il dac è lo slave.

il DAC non ha un clock suo, interno... quindi in questo senso il DAC (chip) è sempre “slave”. È banalmente una questione di posizione fisica degli oscillatori rispetto al chip. Il clock sulla JLSound è il clock locale del DAC.

Nonché l'unico: non ce ne sono altri (a parte quello che trasporta i dati fino all'interfaccia; però, in virtù del link asincrono, questo non ha nulla a che fare con ciò che accade a valle, sul bus I2S).

Sia con l'interfaccia USB/I2s che con l'accrocchio, si raggiunge l'obiettivo di portare all'ingresso del DAC chip un segnale I2s sincrono rispetto ad un unico MCLK, 'ripulito' tramite l'isolatore e risincronizzato immediatamente a monte del dac.

esattamente.

Quello che non riesco a valutare è:

a. con l'accrocchio si hanno due isolamenti e reclocking in cascata,

aspetta... "l'accrocchio" usato (pilotato) come? Tra la JLSounds ed il DAC?

BTW: se non sbaglio nel tuo caso ce ne sarebbero addirittura tre: IIRC due ne hai già (uno sulla JLSounds ed un'altro sulla scheda del DAC).

è utile, ininfluente o dannoso?

se l'oscillatore di clock è a valle dell'isolamento (dell'ultimo isolatore), avere più "barriere" (isolatori e reclocking) in cascata verosimilmente è poco o per nulla utile, ma danni non ne fa.

Viceversa, se metti un isolatore dopo (a valle) dell'oscillatore di clock, fai danno... in quanto fai un vero e proprio massacro in termini di jitter (e se il clock è a monte dell'isolatore, con cosa fai reclocking? con un segnale di clock che ha a sua volta attraversato un isolatore, con un incremento del jitter di uno o due ordini di grandezza rispetto a quello che esce dall'oscillatore?).

b. non sarebbe meglio - in termini assoluti - usare un clock posto nelle immediate vicinanze del dac chip rendendo il dac MASTER ed il trasporto (accrocchio e/o interfaccia) slave?

ah, intendevi in questo senso... SÌ, assolutamente sì.

[marcoc1712]

perché il problema non si pone proprio. Come detto, il procedimento è equivalente ad una doppia conversione DA-AD. Se converti in analogico con un DAC e poi riconverti in digitale con un ADC, puoi forse andare incontro a problemi di XRUN, anche se i clock di DAC ed ADC sono diversi?

No, in effetti, ma l'effetto è lo stesso (periorica ripetizione di campioni o loro eliminazione) se escludi una interpolazione.

che intendi con "esterno"!? c'è un solo master clock, che è quello locale. Anziché essere montato sulla scheda del DAC è montato su quella dell'interfaccia USB/I2S (dal lato "pulito", a valle dell'isolamento galvanico presente sulla stessa), e da li viene inviato al DAC insieme ai dati (ma su una linea dedicata) attraverso il bus I2S.

il DAC non ha un clock suo, interno... quindi in questo senso il DAC (chip) è sempre “slave”. È banalmente una questione di posizione fisica degli oscillatori rispetto al chip. Il clock sulla JLSound è il clock locale del DAC.

Probabilmente è una questione di termini. Per me se è sulla JLSOUND non è locale al DAC (board) ma 'esterno' (posizione fisica), la JLSOUND con il suo CLOCK locale è il MASTER ed il DAC SLAVE (condizione logica).

Potremmo avere il clock locale al dac ma COMUNQUE renderlo SLAVE rispetto alla JLSOUND o ad un controller terzo.

Probabilmente questo diverso uso del termine 'locale' sottointende qualcosa di diverso dalla semplice localizzazione fisica, che mi sfugge. Sicuramente l'errore è mio, puoi spiegare meglio?

io mi riferisco ad uno schema tipo quello rappresentato qui: https://www.sparkfun.com/datasheets/...rds/I2SBUS.pdf ma forse ho interpretato male.

Per quanto detto, se vogliamo questo è un difetto: sarebbe stato meglio montare il clock (i clock: sono due, per le due diverse basi...) direttamente sulla scheda del DAC, quanto più possibile vicino al chip. Però, da un punto di vista logico/funzionale, non cambia nulla. Si ha solo un leggero peggioramento della qualità del segnale (e quindi un aumento del jitter) a causa della trasmissione su una distanza (relativamente) più lunga.

se l'oscillatore di clock è a valle dell'isolamento (dell'ultimo isolatore), avere più "barriere" (isolatori e reclocking) in cascata verosimilmente è poco o per nulla utile, ma danni non ne fa.

Viceversa, se metti un isolatore dopo (a valle) dell'oscillatore di clock, fai danno... in quanto fai un vero e proprio massacro in termini di jitter (e se il clock è a monte dell'isolatore, con cosa fai reclocking? con un segnale di clock che ha a sua volta attraversato un isolatore, con un incremento del jitter di uno o due ordini di grandezza rispetto a quello che esce dall'oscillatore?).

ah, intendevi in questo senso... SÌ, assolutamente sì.

Qui ti perdo, probabilmente proprio per il significato diverso che attribuiamo al termine 'locale'.

Vediamo il mio caso.

l'oscillatore è a valle di un isolatore sulla JLSOUND, ma a monte di quello sulla scheda del DAC, a valle del quale avviene l'ultimo reclocking.
Il clock che proviene dalla JLSOUND attraversa l'isolatore sulla scheda del DAC o no? (io direi di no) è per questo che descrivi il clock come 'locale' anche se proviene dalla JLSOUND?

[bigtube]

l'oscillatore è a valle di un isolatore sulla JLSOUND, ma a monte di quello sulla scheda del DAC, a valle del quale avviene l'ultimo reclocking.
Il clock che proviene dalla JLSOUND attraversa l'isolatore sulla scheda del DAC o no? (io direi di no) è per questo che descrivi il clock come 'locale' anche se proviene dalla JLSOUND?

il clock della JLSounds sta sulla parte isolata e codifica il timing per il DAC ....mi pare

[marcoc1712]

il clock della JLSounds sta sulla parte isolata e codifica il timing per il DAC ....mi pare

Si, appunto, è a valle dell'isolatore della JLSOUND ma a monte di quello del DAC, però - secondo me - MCLK NON passa per quest'ultimo, quindi entra direttamente 'in pancia' al reclocker sulla scheda DAC.

p.s.

Dalla foto si vede bene che la JLSOUND potrebbe anche essere sera 'slave' rispeto ad un MCLK esterno agendo sull'apposito jumper.

[UnixMan]

No, in effetti, ma l'effetto è lo stesso (periorica ripetizione di campioni o loro eliminazione) se escludi una interpolazione.

l'ASRC è tutto una “interpolazione”: tutti i campioni in uscita sono ricalcolati ex-novo e, in generale, non sono mai uguali a quelli in ingresso... (è tutto fuorché "bit perfect").

Probabilmente è una questione di termini. Per me se è sulla JLSOUND non è locale al DAC (board) ma 'esterno' (posizione fisica), la JLSOUND con il suo CLOCK locale è il MASTER ed il DAC SLAVE (condizione logica).

in questo senso (cioè, dal punto di vista logico) è sempre così: il DAC è sempre "slave" del clock che lo comanda.

Potremmo avere il clock locale al dac ma COMUNQUE renderlo SLAVE rispetto alla JLSOUND o ad un controller terzo.

certamente. È ciò che ad es. accadeva nella maggior parte dei casi con l'S/PDIF: master clock sulla sorgente ("trasmettitore"), clock locale "slave" (VCXO controllato da un PLL) sul "ricevitore" (DAC). Ma era (e sarebbe ancora) una cosa pessima.

Probabilmente questo diverso uso del termine 'locale' sottointende qualcosa di diverso dalla semplice localizzazione fisica, che mi sfugge.

sì, in effetti il termine presenta una discreta dose di ambiguità. Tra le altre cose può riferirsi tanto alla posizione "fisica" quanto (più spesso) a quella "logica". Per giunta, se ci riferiamo alla distanza fisica, c'è un problema di fondo: cosa significa "locale"? Se è a 1cm di distanza è locale? e se è a 5cm? se è a 10cm? ecc...

Ulteriore ambiguità nasce anche dai termini "master" e "slave", che possono essere utilizzati in una miriade di contesti diversi, con significati ed implicazioni diversi.

In particolare, in questo contesto io mi riferivo al/ai clock, mentre, nello schema che citi:

io mi riferisco ad uno schema tipo quello rappresentato qui: https://www.sparkfun.com/datasheets/...rds/I2SBUS.pdf

ci si riferisce al bus, cioè a quale dei due dispositivi connessi agli estremi del bus è il "bus master". Se non vado errato, in questo senso i DAC sono sempre "slave" (d'altro canto sono solo dei "ricevitori", non hanno nulla "da trasmettere").

Tornando al discorso sul significato di "locale" tieni conto che, normalmente, l'intero bus I2S è considerato tale. D'altro canto (per quanto recentemente varianti sul tema siano state utilizzate in qualche modo anche per connessioni tra apparecchi diversi, su distanze relativamente lunghe) il bus I2S nasce per l'interfacciamento diretto tra elementi (tipicamente, chip) diversi di uno stesso circuito. Cioè, per l'appunto, proprio come "bus locale".

Vediamo il mio caso.

l'oscillatore è a valle di un isolatore sulla JLSOUND, ma a monte di quello sulla scheda del DAC, a valle del quale avviene l'ultimo reclocking.
Il clock che proviene dalla JLSOUND attraversa l'isolatore sulla scheda del DAC o no? (io direi di no)

purtroppo invece temo proprio di sì: se non lo facesse dovrebbe esserci un collegamento di massa diretto, che annullerebbe l'isolamento (e renderebbe del tutto inutile porre degli isolatori sulle altre linee).

Non per caso c'è chi suggerisce di by-passare quegli isolatori...

(ma, a questo punto, direi che ti convenga piuttosto buttare un occhio sulle nuove schede realizzate da Dario per Giovanni: sostituendo la scheda DIYINHK con quelle + un adeguato I/V di uscita, magari proprio quello con gli AD844, dovresti fare un bel salto in avanti).

è per questo che descrivi il clock come 'locale' anche se proviene dalla JLSOUND?

No. Intendevo "locale" nel senso che è quello che comanda il bus I2S (e quindi il DAC) ed è "locale" rispetto a tale bus: è generato localmente ed è indipendente, non arriva "da un'altra parte" (e.g., dal PC, dal bus USB, ecc), né è sincronizzato con (slave di) alcun altro clock "remoto" (in questo caso nel senso di "esterno" / estraneo rispetto al bus I2S).

Inoltre, se il circuito è assemblato con un minimo di criterio (schede dell'interfaccia USB e del DAC disposte in modo da minimizzare la lunghezza dei collegamenti del bus I2S, come mi pare sia anche nel tuo caso), può considerarsi "locale" anche dal punto di vista della distanza fisica rispetto al DAC (pochi cm).

[UnixMan]

Dalla foto si vede bene che la JLSOUND potrebbe anche essere sera 'slave' rispeto ad un MCLK esterno agendo sull'apposito jumper.

sì. In tal caso si esclude il clock locale (gli oscillatori presenti su quella scheda) e si utilizza quello fornito dall'esterno. In effetti quel jumper potrebbe essere usato anche per utilizzare schede DAC che hanno i clock "a bordo" (riportando quello "indietro" alla JLSounds), ma in realtà credo sia stato pensato per poter utilizzare la sua “Oscillator board” con i Crystek.

[marcoc1712]

(ma, a questo punto, direi che ti convenga piuttosto buttare un occhio sulle nuove schede realizzate da Dario per Giovanni: sostituendo la scheda DIYINHK con quelle + un adeguato I/V di uscita, magari proprio quello con gli AD844, dovresti fare un bel salto in avanti).

Non ne dubito, ma il mio scopo primario è capire, poi vorrei applicare quanto ho capito a qualcosa con ingresso da Ethernet (portrebbe essere la BBB o altro).

Il progettto di Giovani non usa I2S ma un segnale già predisposto per il 1704 che la JLSOUND può fornure direttamente, evitando così la 'colla logica', al di là di questo, non ha prevede isolamento o reclocking, quindi non necessita del MCLK.

Deve necessariamente essere abbinato alla JLSOUND o a qualcosa di anologo in grado di fornre un segnale 'corretto' per com'è, non potrebbe essere abbinato direttamente a nessun SOB, sia per i noti problemi di clock che per la necessaria conversione di formato.

Il mio dac, per esempio, ma credo anche quelli della stessa serie basati sugli AK, prevedono un isolamento del segnale i2s (DATA, WS e BCLK), mentre "The MCK from the I2S input is used to drive the input flip flop for FIFO reclock" e "The reclock quality depends on the jitter of MCK, When used with our XMOS PCB, the MCK is connected to the low jitter low phase noise NDK oscillator directly".

Non so se questo rompa o meno l'isolamento (ma allora non ne capisco bene il senso)., ma direi che MCLK non passa attraverso l'isolatore.Non sono riuscito a trovare informazioni in merito a come funzioni il "Analog Device AN207" usato per il fifo ed il reclocking, potrebbe essere lui a realizzare anche l'isolamento?

[DacPassion]

Forse è per questo che sull'utilizzo del segnale I2S del raspberry ci sono pareri discordanti sulla qualità finale? ...e guarda caso chi dice che suona bene, se non erro, usa dac ASRC

[marcoc1712]

Forse è per questo che sull'utilizzo del segnale I2S del raspberry ci sono pareri discordanti sulla qualità finale? ...e guarda caso chi dice che suona bene, se non erro, usa dac ASRC

o, per tornare la dove siam partiti, 'accrocchi' che rendano asincrono e 'mascherino' il collegamento verso il PI usando DAC 'slave'. Ma, come ha fatto notare Paolo, c'è chi sostiene esattamente il contrario.