Pagina 9 di 14

Inviato: 17 gen 2009, 23:48
da LuCe
Tra non molto saranno disponibili i primi dettagli della piattaforma DAC custom open-source basata su FPGA di cui sto seguendo lo sviluppo insieme ad un team internazionale (per chi ha seguito un po', parlo del DAC di Pierre "peufeu"). Ci sarà l'ingresso USB asincrono e molte altre interfacce... non sarà propriamente economico, ma dovrebbe risolvere la questione della mancanza di qualcosa di DIY fatto bene in tal senso.

Se ti può interessare... :)

Giaime Ugliano

Originally posted by Giaime - 17/01/2009 :  10:33:02

Certo che mi può interessare !!
Intanto ho cercato in rete Pierre peufeu e devo dire che il suo sito è molto interessante. Beato lui che ha così tanto tempo...
L'idea di prendere quelle schedina con FPGA Xiinx è decisamente buona: Ci ho lavorato (a lavoro) qualche tempo fa ed effettivamente sono forti.
Non mi convice pero l'idea di avere il macinabit ethernet colegato a un computer (in cantina?) che fa da host. Sinceramente trovo scomodissimo l'idea di passare cavi per casa, di avere un PC nascosto da qualche parte che devo accendere prima di ascoltare la musica ( se sempre acceso anche peggio: buttare così l'elettricità è una bestemmia).

Ci sono a pari prezzo delle schedine uPC che si comprano allo stesso prezzo delle FBGA base boards e sono dei veri e propri computer (e poi io ce l'ho già ; ) ). Ti permettono di fare un sistema stand alone e il software è già stato scritto da altri: vuoi mettere.
Certo si potrebbe mettere l' FBGA a valle del uPC....ma a quel punto quelle schede mi sembrano eccessive e comunque necessitano di drivers e software scritto apposta.
Personalmente piace di più l'idea di utilizzare una interfaccia USB plug and play in modo che il PC la veda come una scheda audio. Mi sembra che quelle che ci sono in giro (tipo le PCM 2707) non permettono un collegamento asincrono, ma so che ci sono delle interfacce USB general purpose: non so se qualcuno di voi ci ha già messo il naso e sa dirmi se la strada è praticabile oppure no.

Ciao LuCe

Inviato: 17 gen 2009, 23:58
da PPoli
Sinceramente trovo scomodissimo l'idea di passare cavi per casa, di avere un PC nascosto da qualche parte che devo accendere prima di ascoltare la musica ( se sempre acceso anche peggio: buttare così l'elettricità è una bestemmia).
Wake up on keyboard.
I vecchi BIOS l'avevano. Sui nuovi non sono aggiornato.
ma so che ci sono delle interfacce USB general purpose: non so se qualcuno di voi ci ha già messo il naso e sa dirmi se la strada è praticabile oppure no.
Io ho preso la M-Audio Transit e giro USB2 -> Toslink 24/96. Se ne è parlato nell'altro tread sugli HD. Intendevi questo o una vera e propria trasmissione asincrona? Ma poi, anche ammesso che trovi il ricevitore giusto, Windows lo vedrà? E nel caso come scheda audio? Perchè se non la vedi come scheda audio devi poi trovare anche il software che invia al DAC i dati. Quelli in giro si appoggiano perlappunto ad una scheda audio, senza che nemmeno tu te ne accorga.

Inviato: 18 gen 2009, 01:47
da Giaime
Personalmente piace di più l'idea di utilizzare una interfaccia USB plug and play in modo che il PC la veda come una scheda audio.

Originariamente inviato da LuCe - 17/01/2009 :  17:48:02
Il sito non è aggiornatissimo, si è abbandonata l'interfaccia ethernet per il momento, per passare all'USB per il quale dovrebbero essere resi disponibili in futuro i drivers per Windows e Linux.

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 18 gen 2009, 01:55
da Giaime
Io ho preso la M-Audio Transit e giro USB2 -> Toslink 24/96. Se ne è parlato nell'altro tread sugli HD. Intendevi questo o una vera e propria trasmissione asincrona?

Originariamente inviato da PPoli - 17/01/2009 :  17:58:21
In realtà la M-Audio Transit usa il TAS1020, che può essere usato in modo asincrono, non è detto che in quella particolare implementazione lo sia (lato PC ci vogliono dei drivers, cosa che con i modi sincroni tipicamente è inutile, Windows li riconosce già perfettamente). Il clock è fornito da un oscillatore a porte logiche, con un quarzo a basso profilo: in caso di reale funzionamento asincrono, non si va a guadagnare moltissimo, vista la bassa qualità del clock risultante. Inoltre tieni conto che ogni successiva conversione in S/PDIF, trasmissione e decodifica rovinano ulteriormente il segnale introducendo jitter... la regola generale è: più sono corte le connessioni non puramente informatiche (quindi I2S, S/PDIF, USB sincrono...) tra sorgente e DAC (inteso come chip, non come apparecchio), meglio suona :)

Insomma se fosse asincrona, tutte le potenzialità di questo tipo di funzionamento sono comunque sprecate...

Immagine

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 18 gen 2009, 02:47
da marziom
Tra non molto saranno disponibili i primi dettagli della piattaforma DAC custom open-source basata su FPGA di cui sto seguendo lo sviluppo insieme ad un team internazionale (per chi ha seguito un po', parlo del DAC di Pierre "peufeu"). Ci sarà l'ingresso USB asincrono e molte altre interfacce... non sarà propriamente economico, ma dovrebbe risolvere la questione della mancanza di qualcosa di DIY fatto bene in tal senso.

Se ti può interessare... :)

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys





Originariamente inviato da Giaime - 17/01/2009 :  10:33:02
come affrontate, e risolvete, il problema del jitter?

_____________________
I want to see a beatiful girl... no 00110010111010011001...

Inviato: 18 gen 2009, 03:23
da Echo
Personalmente piace di più l'idea di utilizzare una interfaccia USB plug and play in modo che il PC la veda come una scheda audio.

Originariamente inviato da LuCe - 17/01/2009 :  17:48:02
Il sito non è aggiornatissimo, si è abbandonata l'interfaccia ethernet per il momento, per passare all'USB per il quale dovrebbero essere resi disponibili in futuro i drivers per Windows e Linux.

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys





Originariamente inviato da Giaime - 17/01/2009 :  19:47:12
visto che tu che segui la faccenda, pensi ci siano speranze di driver anche per Mac osx?

è prevista la realizzazione di pcb ...e quindi sarà fattibile anche da quelli che non sono autocostruttori "avanzati"??

-------------------------
http://gabrielligiorgio.wordpress.com/

Inviato: 18 gen 2009, 03:28
da PPoli
Inoltre tieni conto che ogni successiva conversione in S/PDIF, trasmissione e decodifica rovinano ulteriormente il segnale introducendo jitter... la regola generale è: più sono corte le connessioni non puramente informatiche (quindi I2S, S/PDIF, USB sincrono...) tra sorgente e DAC (inteso come chip, non come apparecchio), meglio suona
Ci sarà l'ingresso USB asincrono e molte altre interfacce...
Non sono in contraddizione le due cose? Intendo molte interfacce significa usare comunque un selettore di ingressi. O pensi di fare tutti gli ingressi con conversione diretta I2S (senza passare da SPDif) e gestisci il selettore a livello "software".

Inviato: 18 gen 2009, 06:14
da Giaime
come affrontate, e risolvete, il problema del jitter?

Originariamente inviato da marziom - 17/01/2009 : 20:47:04
Qualsiasi sorgente sarà in slave mode ad un clock generato localmente con la massima cura, che risincronizza i segnali giusto prima della conversione. Questo implica l'uso di protocolli USB asincroni, S/PDIF in slave mode da PC (facile, molte schede audio lo prevedono) o da meccanica cd tradizionale o multiformato/informatica (più avanzato, bisogna creare un ingresso master clock sulla meccanica).
visto che tu che segui la faccenda, pensi ci siano speranze di driver anche per Mac osx?

è prevista la realizzazione di pcb ...e quindi sarà fattibile anche da quelli che non sono autocostruttori "avanzati"??

Originariamente inviato da Echo - 17/01/2009 : 21:23:22
A quanto ho capito (non mi sto occupando io del software) i drivers non dovrebbero girare direttamente sotto il sistema operativo, ma in un ambiente multi-piattaforma specifico per l'USB (libusb). Successivamente si pensava di implementare i "driver" intesi in senso tradizionale, magari se ci fosse qualche softwarista interessato a dare una mano... :)

Non è un progetto per principianti, questo sicuramente: è probabile che per adattarlo alle singole specifiche esigenze individuali bisogna sviluppare da sè dei moduli e scrivere un po' di codice VHDL/Verilog. Non è stato ancora deciso tutto, ma in ogni caso la scelta è quella di non aver paura a usare componentistica SMD e schede a due layer, l'idea del progetto è comunque rivolta ad un'autocostruzione "evoluta". Si è parlato di far fare le schede ma non c'è ancora nulla di definitivo.
Inoltre tieni conto che ogni successiva conversione in S/PDIF, trasmissione e decodifica rovinano ulteriormente il segnale introducendo jitter... la regola generale è: più sono corte le connessioni non puramente informatiche (quindi I2S, S/PDIF, USB sincrono...) tra sorgente e DAC (inteso come chip, non come apparecchio), meglio suona
Ci sarà l'ingresso USB asincrono e molte altre interfacce...
Non sono in contraddizione le due cose? Intendo molte interfacce significa usare comunque un selettore di ingressi. O pensi di fare tutti gli ingressi con conversione diretta I2S (senza passare da SPDif) e gestisci il selettore a livello "software".

Originariamente inviato da PPoli - 17/01/2009 :  21:28:39
A quel punto non è importante la selezione degli ingressi, infatti è lasciata piuttosto libera: qualsiasi jitter accumulato in questi collegamenti è del tutto ininfluente a causa del funzionamento slave mode, e del reclocking effettuato subito prima del DAC. Gli errori di temporizzazione sono insomma tollerati finchè non vanno ad introdurre errori sui dati... cosa piuttosto rara (bisogna mettersi d'impegno :D ). Si pensava comunque di lasciare la possibilità di entrare in S/PDIF tradizionale, non slave mode, con la possibilità di implementare un ASRC.

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 19 gen 2009, 00:29
da Echo
Non è un progetto per principianti, questo sicuramente: è probabile che per adattarlo alle singole specifiche esigenze individuali bisogna sviluppare da sè dei moduli e scrivere un po' di codice VHDL/Verilog. Non è stato ancora deciso tutto, ma in ogni caso la scelta è quella di non aver paura a usare componentistica SMD e schede a due layer, l'idea del progetto è comunque rivolta ad un'autocostruzione "evoluta". Si è parlato di far fare le schede ma non c'è ancora nulla di definitivo.
...smd schede dual layer.... vi seguirò con grande passione e invidia ...ma non sarò mai in grado di imbarcarmi in una cosa del genere ; )

-------------------------
http://gabrielligiorgio.wordpress.com/

Inviato: 19 gen 2009, 02:26
da Giaime
...smd schede dual layer.... vi seguirò con grande passione e invidia ...ma non sarò mai in grado di imbarcarmi in una cosa del genere ; )

Originariamente inviato da Echo - 18/01/2009 :  18:29:26
Sarà mica difficile stampare una scheda a doppia faccia, o saldare qualche componente SMD (non IC complicati, ma opamp, resistenze, condensatori...)? :)

Per le schede comunque si possono sempre far fare professionalmente...

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 19 gen 2009, 20:22
da LuCe
Sono d'accordo, eccetto gli integrati ball grid saldare l'SMD non è un problema basta avere buina vista da vicino, e un buon saldatore.
Anche i dual Layer non sono un problema anche se credo che non ci saranno tanti integrati da richiederlo. Forse volevi dire multistrato.

Quello che invece mi dispiace è che la cosa al momento sia TOP SECRET :(
Sinceramnte se devo copiare un progetto fatto intermentre da altri posso comprarmi il prodotto già fatto. Non so per voi, per me la parte divertente è la progettazione, mentre saldare, assemblare ecc. è una gran rottura di co...oni :x

Ciao
LuCe

Inviato: 19 gen 2009, 20:43
da Giaime
Sinceramnte se devo copiare un progetto fatto intermentre da altri posso comprarmi il prodotto già fatto. Non so per voi, per me la parte divertente è la progettazione, mentre saldare, assemblare ecc. è una gran rottura di co...oni :x

Originariamente inviato da LuCe - 19/01/2009 :  14:22:59
Anche questo sarà più chiaro quando sarà pubblico qualcosa (dovrebbe succedere a breve, la proposta l'ho fatta e vediamo cosa dicono gli altri).

In realtà il progetto è totalmente modulare. Le uniche cose inderogabili sono la scheda che monta l'FPGA (che è una demo-board già bella e fatta, non bisogna saldare nulla). Per i moduli sono assegnate solo le interfacce (il tipo di connettori e il loro pinout) ma il modulo stesso è libero, si è liberi di implementare i singoli stadi come si preferisce.

E' piuttosto lontano insomma dall'impostazione di un progetto "chiuso", come può essere quello del my_ref ad esempio, che è solo di pubblico dominio, non "aperto".
Per questo viene definito "open source", similarmente al software libero, dove spesso (penso ad una distro di Linux) il kernel si mantiene fisso e si interviene sulle interfacce grafiche, i drivers per le periferiche, si aggiungono programmi di uso comune, etc etc... di fatto il software diventa interamente personalizzabile, così come questo progetto di DAC.

Ovviamente, in parallelo a questa impostazione "open source" ci saranno anche dei moduli "ufficiali" (schema e disegno PCB, probabilmente anche qualche gruppo d'acquisto per le schede già pronte, se si raggiunge una certa massa critica di partecipanti - ed è per questo che vorrei coinvolgere più persone possibile...) per chi non ha voglia di svilupparli per conto proprio, ma vuole solo assemblarli.

L'altra cosa non personalizzabile (ma solo in apparenza) è il software caricato sull'FPGA: per adesso l'unica certezza è che questo si incarica di interfacciare il DAC col protocollo USB (non credo che nessuno abbia voglia di scriverselo se si trova già bello e fatto! :D , non è qui il piacere del diy). Ulteriori funzioni, come l'interfaccia verso schermi LCD, pulsanti, telecomandi, altri tipi di ingressi digitali etc etc, come i moduli hardware saranno liberi: anche qui ci saranno delle versioni "ufficiali" ma ciascuno (imparando un po' di VHDL/Verilog) dovrebbe essere in grado di modificarseli a piacere.


Si potrà quindi decidere, se tutto va bene, a che gradino salire la scala: c'è chi si fermerà al primo gradino, con un progetto "minimale" (ad es. un singolo DAC stereofonico con ingresso USB e uscita a opamp, senza slave mode alla sorgente) usando il software sviluppato corredato dalle schede "ufficiali" magari con già qualche componente difficile da saldare montato.
Qualcun altro potrà salire il gradino successivo inserendo tra le funzionalità software già pronte qualcosa di più avanzato (come la possibilità di tenere le sorgenti in slave mode), magari sviluppandosi da solo un modulo I/V come più gli piace, o un modulo clock.

Sicuramente ci sarà chi arriva fino all'ultimo gradino, modificando pesantemente il software per usare, chessò, un LCD grafico, magari implementando tutti moduli custom, sia alimentazione che sezione digitale che sezione analogica come meglio preferisce.

Ripeto, per mantenere l'impostazione DIY senza però essere costretti ad imparare a programmare l'FPGA, si può tranquillamente partecipare al progetto: se non si vogliono usare i moduli "di default" ce li si può sviluppare da soli, non è difficile creare un modulo DAC (o un modulo clock, un modulo ricevitore S/PDIF, un modulo I/V a valvole - transistor - mosfet - come si preferisce) sapendo già cosa deve entrare e cosa deve uscire.

(Il problema casomai è farlo bene: è per questo che ci saranno moduli "ufficiali". Al progetto partecipa gente che con i circuiti digitali ad alta velocità ci lavora, questo dovrebbe garantire l'assenza dei soliti errori degli hobbisti, abituati ai circuiti analogici a bassa frequenza, quando si mettono fare un DAC).

Anche l'alimentazione è piuttosto libera (anzi forse è l'area dove probabilmente non ci sarà niente di ufficiale).

A me sembra invece che con questo tipo di impostazione, forse è vero il contrario, lasciando troppa libertà al singolo diyer si possono compromettere le prestazioni e il principio di fondo sul quale nasce il progetto, ad esempio con chip DAC obsoleti, uso del NOS, stadi d'uscita ridicoli e mal progettati etc etc... ma l'impostazione del progetto è "open source" e tale resterà. Chi parteciperà sarà libero di rovinarne (o migliorarne) le prestazioni come meglio crede insomma 8)

Non vorrei comunque approfittare del topic di Paolo oltremodo, per ulteriori informazioni nell'attesa di avere una pagina web è possibile contattare Pierre o me come preferite:
http://audio.peufeu.com/

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 22 gen 2009, 16:36
da PPoli
Che libidine i files 24/96.

Ora si che si sente la differenza.

Ma che li stanno ancora a fare i CD?

PS piccola confessione: sto usando i "sampler" di Naim e Linn. Immagino non ci abbiano buttato dentro il peggio che avevano a disposizione.

Inviato: 22 gen 2009, 21:34
da LuCe
Asynchronous reclocking

Ho letto di questa tecnica, e soprattuto dei commenti che la riguardano. Ci sono due categorie di persone:
1) quelle che avendola provata sono entusiati
2) Quelle che la bocciano a priori perchè la cura è peggiore del male.

Effettivamente le tesi degli apparteneti al secondo gruppo sono sulla carta corrette: si elimina si il jitter sui clock ma si introduce una modulazione che ricorda il wow & flutter.
Personalmente non ho mai provato pertanto la prima domanda che vi faccio è:
"Come suona secondo la vostra esperienza un DAC con applicato l'asynchronous reclocking"?
E poi....
"Ci sono altre tecniche similari capaci di eliminare o perlomeno ridurre il rumore di fase al livello dei segnali I2S ?"

Grazie
LuCe

Inviato: 22 gen 2009, 21:56
da Echo
Che libidine i files 24/96.

Ora si che si sente la differenza.

Ma che li stanno ancora a fare i CD?

PS piccola confessione: sto usando i "sampler" di Naim e Linn. Immagino non ci abbiano buttato dentro il peggio che avevano a disposizione.


Originariamente inviato da PPoli - 22/01/2009 :  10:36:48
guarda sinceramente io sono rimasto meravigliato anche da file 24/96 acquisiti da giradischi analogico quindi....; )

-------------------------
http://gabrielligiorgio.wordpress.com/

Inviato: 22 gen 2009, 22:27
da PPoli
Si, ho anche di quelli e la differenza con il 44.1/16 è evidente.
Magari sui formati digitali continuiamo nella discussione in corso.

Prima magagna: con il selettore degli ingressi e il segnale a 96kHz il ricevitore del Buffalo non tiene agganciato il segnale. Funziona, cioè suona. Un canale perfettamente, ma l'altro gracchia (leggermente) e ogni tanto su entrambi c'è una piccola pausa (decimi di secondo).

Sono quasi certo che la colpa sia del mini-trasformatorino di disaccoppiamento che c'è anche sull'ingresso Toslink. Sicuramente filtra troppo sopra i 50kHz (a 48 funziona perfettamente). Il ricevitore RX176 sembra accettare il segnale anche a 96kHZ.

Invece con il ricevitore iniziale (basato sul Toshiba TORX147L, max96kHz, preso sempre da Twistepear) collegato direttamente al ricevitore SPDif del DAC nessun problema. Ora da Twistedpear spediscono i TORX142L che arrivano sino a 192kHz. Il problema semmai è trovare i files e passarglieli.

Stasera provo a eliminare il trasformatore di ingresso dalla schedina del selettore e/o collegarci il 147.

Inviato: 24 gen 2009, 00:44
da Giaime
Asynchronous reclocking

Originariamente inviato da LuCe - 22/01/2009 :  15:34:06
Qualche spiegazione ben fatta:
http://www.lessloss.com/faq.html?q=asyn ... reclocking
http://www.diyhifi.org/forums/viewtopic.php?f=2&t=967

opinione mia: è una cazzata.
"Ci sono altre tecniche similari capaci di eliminare o perlomeno ridurre il rumore di fase al livello dei segnali I2S ?"

Originariamente inviato da LuCe - 22/01/2009 : 15:34:06
Certo, far si che questo non conti niente, ovvero facendo in modo di asservire il clock del tuo generatore di segnali I2S ad un master clock a basso rumore di fase, e poi fare un reclocking sincrono subito prima del chip di conversione D/A...

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 24 gen 2009, 05:37
da LuCe
Certo che quel tizio del "lessloss" è gran venditore di aspirapolveri !!!!
Sebbene mi trovi abbastanza in linea con le sue asserzioni, il suo modo di fare aprioristico e dogmatico mi fa dubitare delle mie certezze per il solo fatto che sono anche le sue :x :D
- in linea col fatto che i convertiori parallelo siano migliori dei sigma delta
- in linea con le considerazioni sull'asynchronous reclocking
- meno col syncronous reclocking: se hai un solo clock a che ti serve ricloccare per ben 2 volte? Penso che abbia benefici perchè i latchettini "aiutano" con gli integrati bastardi, e non che li abbia per un reclock inutile.
- in parziale disaccordo col filtro digitale. Parziale perchè sulla teoria la penso come lui però sul mio lettore ciddì è bypassato: e ca22o se suona meglio! Perchè ? Boh !

questa sera ho fatto una scoperta: stavo leggendo i datasheet del PCM1794A ( a proposito come suona? ) ed ho trovato scritto che:
" il clock di parola deve essere sicronizzato col clock del DAC ".
E mi sono detto: "ecco (forse) spiegato perchè molti sostengono che l'asyncronous reclockin funziona bene." In un sistema senza sovracampionatore ( o bypassato) che è l'unico dispositivo capace, in certa misura, di mettere d'accordo due clock differenti, la tecnica dell'asynchronous reclockin è efficace perchè indispensabile.
Puo essere?

Colgo l'occasione per chiderevi innanzitutto di corregermi se ho scritto delle ca22ate e poi:

quali sono i migliori convertitori attualmente in produzione?

Ciao
LuCe

Inviato: 24 gen 2009, 18:46
da Giaime
Certo che quel tizio del "lessloss" è gran venditore di aspirapolveri !!!!

Originariamente inviato da LuCe - 23/01/2009 :  23:37:11
E' vero, e forse non era il caso di linkare un sito commerciale per dare spiegazioni tecniche. Fatto sta che tecnicamente non dice nulla di falso... anzi, la filosofia del "reclocking sincrono" è alla base anche del progetto di DAC che sto seguendo...
- in linea col fatto che i convertiori parallelo siano migliori dei sigma delta

Originariamente inviato da LuCe - 23/01/2009 : 23:37:11
Questa è solo un'opinione, non supportata dai fatti: io ti posso portare un fatto, che uno dei migliori lettori CD che abbia mai ascoltato (Accuphase DP-67) monta convertitori sigma-delta... quindi? :)
- meno col syncronous reclocking: se hai un solo clock a che ti serve ricloccare per ben 2 volte? Penso che abbia benefici perchè i latchettini "aiutano" con gli integrati bastardi, e non che li abbia per un reclock inutile.

Originariamente inviato da LuCe - 23/01/2009 : 23:37:11
Non c'è un doppio reclock, forse su quel sito non è spiegato benissimo. L'idea è quella di generare un master clock pulito, che fa reclocking direttamente sugli ingressi del DAC, in questo modo il jitter è solo quello intrinseco del master clock. Per poter funzionare, però, quest'architettura necessita che i segnali che arrivino al reclocking siano sincroni col master clock, e questo è presto fatto mettendo in slave mode (ossia gli spedisci una copia "sporca" - tanto non è critica - del master clock) l'eventuale sorgente, sia essa un CDP o una scheda audio.
- in parziale disaccordo col filtro digitale. Parziale perchè sulla teoria la penso come lui però sul mio lettore ciddì è bypassato: e ca22o se suona meglio! Perchè ? Boh !

Originariamente inviato da LuCe - 23/01/2009 : 23:37:11
Il motivo del fatto che il NOS suona meglio nei CDP economici è presto detto, e lo descrive molto bene il buon Putzeys:

http://recforums.prosoundweb.com/index.php/t/14651/0/
The real story is two-fold and hinges on the fact that NOS converters are always multibit (ladder) type converters.
1) For one, they derive their sample timing from the latch signal. In oversampled mode, this signal passes through a computation device (the upsampling filter chip) and contains jitter large enough to be clearly discernible on an oscilloscope. I have been told that an old NPC data sheet mentions explicitly not to tie a DAC chip straight to the upsampling filter, but to insert a D-latch between them to get rid of this jitter.
2) The second factor is linked to glitch energy. When a ladder DAC transitions between two codes with a large Hamming distance (many bits changing state at the same time), the relative timing error between the current switches produces a current spike at the output. For example, between code 01000 and 00111 the dac is liable to produce a current spike corresponding to 01111 or 00000. When the sampling rate is reduced, the relative contribution of glitch energy to the output signal is reduced by the same amount (it happens less often). Inside the audio band a NOS converter will have measurably lower distortion.
As a result, it is not a surprise that someone who takes an existing ladder design and jumpers the upsampling filter will actually hear a lot of things improve.
questa sera ho fatto una scoperta: stavo leggendo i datasheet del PCM1794A ( a proposito come suona? ) ed ho trovato scritto che:
" il clock di parola deve essere sicronizzato col clock del DAC ".
E mi sono detto: "ecco (forse) spiegato perchè molti sostengono che l'asyncronous reclockin funziona bene." In un sistema senza sovracampionatore ( o bypassato) che è l'unico dispositivo capace, in certa misura, di mettere d'accordo due clock differenti, la tecnica dell'asynchronous reclockin è efficace perchè indispensabile.
Puo essere?
No perchè il PCM1794 è sigma-delta, e questo tipo di convertitori ha un filtro sovracampionatore non bypassabile (poichè indispensabile al funzionamento intrinseco del convertitore).
La sincronizzazione del LRCK col system clock non è critica in realtà, perchè è quest'ultimo che comanda la conversione (a differenza delle interfacce dei vecchi convertitori, dove era il word clock a comandare la conversione): serve solo ad evitare che il (limitato) registro interno al DAC vada in overflow o underflow, perdendosi parole per strada...
quali sono i migliori convertitori attualmente in produzione?
Quasi tutti i costruttori (Texas Instruments, Analog Devices, AKMED, Cirrus Logic...) offrono convertitori sigma-delta a 24bit dell'ultima generazione, qualcuno ha addirittura in lavorazione convertitori a 32bit dalla "dubbia" utilità pratica :) In più Texas fa ancora il PCM1704, l'ultimo R2R sul mercato.

Sugli ESS Sabre il discorso è più complicato poichè incorporano un ASRC non bypassabile, quindi o piacciono o non piacciono... non c'è modo di usarli nel modo diverso da come sono stati pensati.

Siamo arrivati comunque ad un punto dello sviluppo dei convertitori D/A audio nel quale le limitazioni intrinseche di vecchi convertitori (TDA1541, 1543) sono del tutto superate, rendendo il chip di conversione non più tanto critico nella definizione delle prestazioni complessive. Conta di più ciò che ci sta intorno, la cui influenza si può semplicisticamente definire "jitter", ma ciò non toglie che siano coinvolti problemi di degradazione del segnale difficilmente comprensibili da una platea di hobbisti...

Ciao!
Giaime Ugliano

Don't Be a Wimp. Use NFB and use tons of it.
Bruno Putzeys

Inviato: 24 gen 2009, 23:09
da LuCe
Grazie Gaime, puntuale, preciso e chiaro come sempre.

1) Se ho ben capito Putzeys se ripristinassi il collegamnto tra il filtro sovrampionatore e il DAC (TDA1541) interfacciandolo però con dei latch otterrei un risultato ancora migliore ?
Farei la prova se il mio vecchio Philips (abartizzato :D ) vecchio di 25 anni non avesse la meccanica ed il laser sull'orlo del collasso. E' per questo che mi stò intessando al nuovo.

2) Se ti piace Accuphase DP-67 immagino che il tuo convertitore prefertio dia l' AD1955 nonostante abbia 12dB in meno rispetto alle caratteristiche del PCM1794. Se non ho capito male la tua classifica è AD1955 > PCM1794 > PCM1704. O cosa altro?

Ciao
LuCe

----------------------------------
Al mondo ci sono 10 categorie di persone: quelle che conoscono il binario e quelle no.