Anatomia di un DAC (anzi di molti DAC)

[max]

5 ore fa, scroodge ha scritto:

Un altro fa una critica alla misura

pare tu non abbia capito perchè non è stata criticata la misura ma il senso di  certe implementazioni che migliorano le misure ...... visto che sono superiori alla famosa soglia di udibilità non si sa come e da chi determinata e buttata come al solito  li in mancanza di argomenti

[max]

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

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,   un grado di accuratezza inferiore a quello necessario, ecc.

[max]

5 ore fa, Blec ha scritto:

Quaranta pagine di fuffa cosmica.

quindi? .... ignora e passa oltre se  consideri inutile questo thread, perchè se  scrivi che è fuffa poi dovresti anche argomentare .... ovviamente se hai le competenze per farlo

@Admin questo è lo spirito di partecipazione che auspicate nel Vostro forum?

[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?