Anatomia di un DAC (anzi di molti DAC)

[max]

1 ora fa, Ricky81 ha scritto:

ma come sappiamo inevitabili qua dentro. 

anche no se la moderazione ritiene di intervenire...i richiami dei moderatori ci sono già stati e esistono gli strumenti per escludere dal thread chi a loro giudizio  non vi si attiene 

[Ligo]

25 minuti fa, max ha scritto:

facciamo nomi...prenditi la briga di rileggere i post (facciamo anche gli ultimi visto che sono tanti) del @ilmisuratore e poi scrivi  se riesci a vederci dei contenuti attinenti all'esposizione...nel caso te li fossi persi parlava come solito di miglioramenti inutili perchè ''sopra la soglia di udibilità'' (fissata non si sa da chi), di strumentazioni che dovrebbero produrre misure significative pur avendo, semplificando,  con un grado di accuratezza inferiore a quello necessario, ecc.

I contenuti sono attinenti,  semmai si può discutere se siano corretti.

Gli insulti e le irrisioni sono più sgradevoli che non le confutazioni, anche se fossero sbagliate.

Ripeto: se è una lezione ne prendo atto, altrimenti è una discussione e chi legge immagino abbia i mezzi per farsi un'opinione. Chi scrive può liberamente decidere se vuole o meno dedicare il proprio tempo a farlo, se sì bene, personalmente sono interessato, se no amen, questa notte dormo ugualmente.

 

 

[Andrea Mori]

25 minuti fa, Ligo ha scritto:

I contenuti sono attinenti,  semmai si può discutere se siano corretti.

Gli insulti e le irrisioni sono più sgradevoli che non le confutazioni, anche se fossero sbagliate.

Ripeto: se è una lezione ne prendo atto, altrimenti è una discussione e chi legge immagino abbia i mezzi per farsi un'opinione. Chi scrive può liberamente decidere se vuole o meno dedicare il proprio tempo a farlo, se sì bene, personalmente sono interessato, se no amen, questa notte dormo ugualmente.

 

 

Dire a qualcuno che non ha alcuna competenza tecnologica quando effettivamente non la ha non è un insulto. E' un dato di fatto.

Non c'è alcuna lezione ed alcun professore, c'è solo un umile hobbista che sta cercando di condividere le sue esperienze maturate in decine di anni di studio, in questo caso in tema di tecnologia e non di litanie ripetute fino alla noia. 

I professori sono altri, ad esempio Bruno Putzeys, ovviamente snobbato pure lui da chi porta la verità assoluta.

Nella mia visione sicuramente limitata il vero insulto è la mancanza di umiltà.

[Bagolon]

5 ore fa, Ligo ha scritto:

Trovo anche io la lezione interessante ma ogni volta che qualcuno osa fare osservazioni magari sbagliando, non ho le competenze per stabilirlo, c'è la minaccia del "io non gioco più,  arrangiatevi", seguito dal coro di preghiere a restare con successivo ripensamento e rientro. A me sembra una posizione da professore di scuola superiore  più che da forum,  dove il contraddittorio è naturale e gli interlocutori non si scelgono secondo i propri desideri.

Nella mia vita non sono stati molti i professori che mi hanno davvero lasciato qualcosa e nessuno di loro aveva l'atteggiamento del professore.

+++

[Andrea Mori]

Riprendo l'argomento descrivendo la tecnologia utilizzabile per eliminare o almeno mitigare i problemi legati al Jitter, o meglio agli errori temporali nella conversione. Ma prima un acceno alla fonte del Jitter.

Normalmente il problema nasce dalla sorgente e non dal DAC stesso. Più o meno, salvo rare eccezioni, il segnale che arriva al DAC dalla sorgente è carico di jitter.

Se si usa il PC come sorgente e si preleva il segnale dall'interfaccia USB, il clock è generato da una macchina che è nata per fare tutt'altro, e non solo il jitter è elevato, ma passano sul bus anche interferenze a radio frequenza (RFI) dato che il PC è praticamente un trasmettitore UHF.

Se l'interfaccia è I2S over HDMI probabilmente ancora peggio, i segnali LVDS sono anch'essi carichi di jitter.

Peggio ancora l'S/PDIF, dove il clock è incapsulato nei dai e un PLL dovrà ricostruirlo all'arrivo.

Se poi la comunicazione è ottica peggiora ulteriormente, poiché la trasmissione ottica è pessima dal punto di vista del jitter.

Quindi il problema del jitter non si manifesta all'interno del DAC, ma viene trasferito al DAC dalla sorgente.

Come si vede nell'immagine allegata il jitter si genera nella sorgente digitale e poi viene trasferito al DAC tramite l'interfaccia di comunicazione.

Se il DAC è sincrono, come nell'immagine, inevitabilmente si accollerà tutto il jitter proveniente dalla sorgente e ne verrà influenzato nel processo di conversione, dato che in architettura sincrona il DAC utilizzerà il clock proveniente dalla sorgente per commutare i suoi interruttori.

Chiarito questo punto nei prossimi commenti descriverò alcune tecniche più o meno efficaci per limitare gli effetti del jitter.

[ilmisuratore]

30 minuti fa, Andrea Mori ha scritto:

Dire a qualcuno che non ha alcuna competenza tecnologica quando effettivamente non la ha non è un insulto. E' un dato di fatto

Anche te dimostri di non avere nessuna competenza/esperienza "per determinate cose" è un dato di fatto anche questo 

Ed io intervengo solamente per sottolineare certi aspetti che, in caso di prove reali (non raccontate/ipotizzate) verresti smentito

C'è qualche legge specifica che vieta di sottolineare le cose che non possono essere condivise ?

Credi che questi interventi vertono per andare contro alla persona ? ma ci mancherebbe altro

Se sottolineo determinati aspetti è perché ho la ragionevole fiducia di poterli confutare

Non dovresti arrabbiarti per questo, basterebbe un dialogo più costruttivo che cerca di arrivare anche a possibili prove

La nostra "guerra" se ricordi inizio' proprio da alcune frasi che tempo fa hai affermato e queste frasi a me non stanno bene, non le condivido affatto e tutte le volte che cerchi di avvalorare questo concetto ti richiamerai le mie critiche 

 

[Andrea Mori]

14 minuti fa, ilmisuratore ha scritto:

 

 

14 minuti fa, ilmisuratore ha scritto:

Se sottolineo determinati aspetti è perché ho la ragionevole fiducia di poterli confutare

 

Sicuro, come il DAC MSB taroccato con il PCB penzolante, la madre di tutte le confutazioni.

Le mie competenze sono sicuramente scarse, infatti nessuno ti obbliga a leggere quello che scrivo.

Intervieni come meglio credi, nessuno te lo vieta. Dal canto mio d'ora in poi eviterò accuratamente di rispondere a te e a tutti i tuoi parrots on the shoulder. Dal mio modesto punto di vista anche questo thread è già sufficientemente inquinato, quindi eviterò di promuovere ulteriori inquinamenti.

 

[ilmisuratore]

15 minuti fa, Andrea Mori ha scritto:

Sicuro, come il DAC MSB taroccato con il PCB penzolante, la madre di tutte le confutazioni.

Vedi come sei arrogante ed incoerente ?

Ti avevo dato perfino l'indirizzo del posto in cui era stata effettuata la modifica, me la sono fatta inviare direttamente dal proprietario e tu hai risposto che non te ne fregava nulla

Ora cerchi di prendere in giro ?

A me non piace essere preso in giro, a te si  ?

Sei te che mi stuzzichi, e in malomodo anche

Non troverai da parte mia in nessun post frasi come le tue

Mi limito a non condividere alcune cose che ritengo possano essere confutate, mentre tu non appena si tocca questo argomento ti saltano i nervi

[Andrea Mori]

Il metodo più semplice ed economico per contrastare il jitter proveniente dalla sorgente è quello di eseguire il cosiddetto "reclocking" dei segnali in arrivo prima di inviarli al DAC.

L'immagine rappresenta un semplice schema di principio per effettuare il reclocking.

I segnali I2S provenienti dalla sorgente (o anche gli stessi dopo la decodifica di un ricevitore S/PDIF) vengono inviati agli ingressi dati (D1, D2, D3) di 3 flip-flop contenuti all'interno di un circuito integrato. La caratteristica del flip-flop è quella di ritenere i dati fino all'arrivo di un fronte di salita sull'ingresso clock, a seguito del quale i dati immagazzinati nei registri vengono spostati alle uscite (Q1, Q2, Q3).

Come si evince dall'immagine, il clock fornito ai flip-flop proviene da un oscillatore esterno, che ovviamente deve avere un jitter inferiore a quello della sorgente.

Di conseguenza, i segnali provenienti dalla sorgente verranno ripuliti dal jitter intrinseco, dal momento che questi vengono sincronizzati in un dominio temporale diverso da quello della sorgente, evitando il trasferimento del jitter al DAC che commuterà i suoi interruttori a partire da un clock più pulito piuttosto che da quello della sorgente.

Per funzionare correttamente, il circuito nell'immagine, il clock esterno fornito ai flip-flop deve avere una frequenza almeno doppia a quella massima consentita in ingresso sulla linea di bit clock (BCK), altrimenti si creerebbero problemi di meta-stabilità che produrrebbero errori nel trasferimento dei dati.

Non so se il concetto è chiaro, ovvero non sono sicuro di aver usato termini perfettamente comprensibili, quindi prima di passare a tecnologie più sofisticate rimango a disposizione per chiarire i dubbi sulla tecnica che ho descritto.  

[Zap67]

3 ore fa, Andrea Mori ha scritto:

Se l'interfaccia è I2S over HDMI probabilmente ancora peggio, i segnali LVDS sono anch'essi carichi di jitter.

Su rj45, utilizzato da Metrum/Sonnet e Aqua, è meglio?

ho già letto il post successivo, in ogni caso ti chiedo: ha senso utilizzare filtri usb tra pc/mac e dac, come ad es. IFI, Topping, Holo audio?

[paolosances]

Moderare toni e contenuti.

[fmr59]

7 ore fa, Andrea Mori ha scritto:

Normalmente il problema nasce dalla sorgente e non dal DAC stesso. Più o meno, salvo rare eccezioni, il segnale che arriva al DAC dalla sorgente è carico di jitter.

Andrea, quindi questo potrebbe spiegare perché gli streamer suonano diversi? Iniettano diversi livelli di jitter? E il reclocking, se effettuato dal dac, o se il dac in altro modo è in grado di eliminare questo jitter iniettato dallo streamer, potrebbe anche spiegare perché con alcuni dac cambiare lo streamer non ha effetto sul suono prodotto?

[domenico80]

vado OT :

il jitter ce lo dobbiamo tenere oppure esiste la possibilità di eliminarlo o ridurlo ?

Il DAC di Mori forse riesce ?

[alexis]

Penso che il jitter sia la madre di tutti i mali digitali, ovviamente ve ne sono altri.. mi ricordo che quando andavo di schede Audio PCI/e ne presi una della RME professionale a 16 canali.. non c‘era altro.. ma almeno aveva un ingresso clock, che permetteva di sincronizzare, appunto scheda e dac.. eravamo agli albori, circa 20 anni fa, ma sincronizzando tutto con il clock dcs o apogee big ben.di allora.. il tutto funzionava udibilmente meglio.

oggi come oggi c‘é pure lo switch router con la sua bella rete Ethernet a metterci del suo, e molti audiofili ancora ignorano che lo switch ha anche lui un clock all‘interno.. e che non è un caso che la Aqvox per prima si é messa a produrre switch audiophile.. il cui apporto é udibile e non certo suggestione.

a dirla tutta.. la via del buon o eccellente suono digitale é tutt‘altro che semplice, come qualcuno tende a illudere / credere.. vi sono insidie dappertutto.

[Andrea Mori]

6 ore fa, Zap67 ha scritto:

Su rj45, utilizzato da Metrum/Sonnet e Aqua, è meglio?

ho già letto il post successivo, in ogni caso ti chiedo: ha senso utilizzare filtri usb tra pc/mac e dac, come ad es. IFI, Topping, Holo audio?

Per il trasporto dei segnali I2S, sicuramente l'RJ45 è migliore dell'LVDS su HDMI perché di suo non aggiunge Jitter.

Tuttavia, essendo un semplice mezzo di trasporto, non potrà eliminare il Jitter proveniente dalla sorgente, che verrà inevitabilmente trasmesso al DAC.

Per quanto riguarda l'USB, nel prossimo commento descriverò una tecnica volta ad eliminare o ridurre il jitter della sorgente utilizzando appunto il bus USB.  

[Andrea Mori]

2 ore fa, fmr59 ha scritto:

Andrea, quindi questo potrebbe spiegare perché gli streamer suonano diversi? Iniettano diversi livelli di jitter? E il reclocking, se effettuato dal dac, o se il dac in altro modo è in grado di eliminare questo jitter iniettato dallo streamer, potrebbe anche spiegare perché con alcuni dac cambiare lo streamer non ha effetto sul suono prodotto?

Esattamente, in assenza di reclocking lato DAC o di altre tecnologie delle quali parlerò più avanti, tutto il jitter intrinseco della sorgente viene iniettato nel DAC (o addirittura peggiorato se si usa I2S su HDMI). Pertanto è il jitter dello streamer che influenza il DAC, e quindi differenti livelli di jitter provenienti da streamer diversi influenzeranno più o meno negativamente il processo di conversione implementato nel DAC.

Allo stesso tempo, se nel DAC si usano tecniche volte a isolare la sorgente, il jitter proveniente da quest'ultima potrà essere ridotto o eliminato, tanto che alla sezione di conversione del DAC arriveranno sempre gli stessi segnali puliti, generati nel suo dominio temporale, e quindi la sostituzione di uno streamer con un altro non sarà rilevante a prescindere dal jitter che contiene. 

[Andrea Mori]

1 ora fa, domenico80 ha scritto:

vado OT :

il jitter ce lo dobbiamo tenere oppure esiste la possibilità di eliminarlo o ridurlo ?

Il DAC di Mori forse riesce ?

Non necessariamente dobbiamo tenercelo, ci sono diverse tecniche per ridurlo od eliminarlo. La prima è quella del reclocking lato DAC che ho descritto nell'ultimo commento sul tema, delle altre parlerò nei prossimi commenti.

Per quanto riguarda i miei DAC, mi dispiace ma, come ho già detto, non ne parlerò. 

A maggior ragione visto che qualcuno continua ad insinuare che io abbia secondi fini.

[5mare]

Dopo molto tempo si legge sul forum un argomento molto molto interessante e anche condotto dall'opener con maestria.

Mi piacerebbe avesse uno sviluppo più fluido e che la voglia di protagonismo di certi forumer si plachi.

Spero che @Andrea Mori non abbandoni.