My New DAC PCM1704+AD844

[rogers]

Ian è uno in gamba ed ha fatto un gran lavoro (ho da tempo un esemplare di quella schedina di conversione IIS in altri formati ), ma con la jlsound non serve...
a meno che non voglia lavorare con il TDA1541

[bigtube]

Ian è uno in gamba ed ha fatto un gran lavoro (ho da tempo un esemplare di quella schedina di conversione IIS in altri formati ), ma con la jlsound non serve...
a meno che non voglia lavorare con il TDA1541

Sono d'accordo in pieno. La jlsounds io la trovo perfetta.

[aletas]

Ian è uno in gamba ed ha fatto un gran lavoro (ho da tempo un esemplare di quella schedina di conversione IIS in altri formati ), ma con la jlsound non serve...
a meno che non voglia lavorare con il TDA1541

@Bigtube

Sono sicuro che la JLsounds sia un "must" irrinunciabile sia per le sue performance ma anche e soprattutto perché offre la possibilità di dare lo streaming I2S con i canali L/R già separati senza dover ricorre al chip DF1704 per pilotare i due 1704 mono; questo nel caso di singolo DAC stereo, nel mio caso uso la JLsounds come transport I2S per il processore miniSHARC (crossover 6/8 canali) che però ha l'uscita DATA con lo streaming I2S L/R mescolato e , penso, non adatto a pilotare direttamente i due 1704.

Scusate per la fato fatta con il cellulare




in alto a sin c'è la JLsounds in verticale ed al centro la scheda miniSHARC con il connettore IN/OUT








Come si vede dal pinout l'uscita I2S DATA ha i canali L/R insieme per questo volevo evitare il DF1704 ed usare la scheda di IAN come suggerito da Bigtube

[bigtube]

...........................................

Come si vede dal pinout l'uscita I2S DATA ha i canali L/R insieme per questo volevo evitare il DF1704 ed usare la scheda di IAN come suggerito da Bigtube

Alessandro ....progetto interessantissimo. Frugando in rete dopo aver visto il tuo lavoro mi è capitato di vedere un diyer che in associazione con la tua scheda miniSHARC
preleva l'I2S proprio con una BBB . Potrebbe essere uno sviluppo promettente e adesso capisco meglio che ti darebbe molto vantaggio la scheda di "iancanada".
Penso che anche il Nostro Marco abbia molto interesse per il tuo lavoro.
Il mio pensierino sulla scheda di Ian nasceva proprio dalla voglia di sperimentare quello che tu stai mettendo in pratica. Complimenti.

[marcoc1712]

Alessandro ....progetto interessantissimo. Frugando in rete dopo aver visto il tuo lavoro mi è capitato di vedere un diyer che in associazione con la tua scheda miniSHARC
preleva l'I2S proprio con una BBB . Potrebbe essere uno sviluppo promettente e adesso capisco meglio che ti darebbe molto vantaggio la scheda di "iancanada".
Penso che anche il Nostro Marco abbia molto interesse per il tuo lavoro.
Il mio pensierino sulla scheda di Ian nasceva proprio dalla voglia di sperimentare quello che tu stai mettendo in pratica. Complimenti.

Si, se ne parlava nell'altro THD come complemento del fifo/ reclocker se si vogliono usare DAC "PCM" per usare la terminologia che usa lui. Ne capisco utilità e funzione nel progetto di Alessandro, mentre i miei dubbi sono nella componente a monte: IL FIFO sincrono verso il trasporto e verso il DAC espone il sistema al rischio di XRUN che a frequenze elevate non è poi tanto teorico. L'utilizzo della BBB (ma non credo sia utile con il fifo idi IAN, Giovanni mi posti il link al progetto?) potrebbe risolvere il problema utilizzando il MCLK del Reclocker di IAN in input, ma - come segnala Paolo - rompendo l'isolamento galvanico.

Ci siamo arenati lì, o meglio, mi sono arenato io.

[aletas]

Si, se ne parlava nell'altro THD come complemento del fifo/ reclocker se si vogliono usare DAC "PCM" per usare la terminologia che usa lui. Ne capisco utilità e funzione nel progetto di Alessandro, mentre i miei dubbi sono nella componente a monte: IL FIFO sincrono verso il trasporto e verso il DAC espone il sistema al rischio di XRUN che a frequenze elevate non è poi tanto teorico. L'utilizzo della BBB (ma non credo sia utile con il fifo idi IAN, Giovanni mi posti il link al progetto?) potrebbe risolvere il problema utilizzando il MCLK del Reclocker di IAN in input, ma - come segnala Paolo - rompendo l'isolamento galvanico.

Ci siamo arenati lì, o meglio, mi sono arenato io.

Marco ,puoi indicarmi il 3d per favore? Seguo con molta discontinuità le discussioni e questo mi deve essere sfuggito.
Nel caso specifico di più DAC finalizzati a multi channel per crossover ( no home theater), personalmente preferirei evitare se possibile il reclocking e il buffer FIFO per motivi di delay non facilmente prevedibili e/o gestibili (come sincronizzare le varie schede?) Inoltre da esperienze fatte con la scheda DAM 1021 che ha sia il buffer FIFO che il reclocker, in alcune situazioni si avevano strani comportamenti silenziando un canale e comunque qualcosa non mi convinceva all'ascolto.
Ciò che mi entusiasma nel progetto di Giovanni è proprio l'estrema semplicità/purezza del flusso dati che viene inviato al 1704, semplicità che in questo caso elimina diverse " colle" mettendolo nelle migliori condizioni di lavoro. A mio parere è più importante cercare di ottimizzare la risposta nel domino del tempo intesa come risposta ai transienti dove i filtri antialea fanno ancora sfracelli piuttosto che ottimizzare il dominio temporale con la ricerca di jitter al femtosecondo o isolamenti galvanici ad ogni costo. I positivi riscontri di Giovanni, che di 1704 penso ne abbia esperienza, stanno a indicare che la strada è quella giusta. Nel mio caso specifico ( spero di utilità anche per altri) stò cercando qualcosa di simile alla JLsounds ma che faccia solo da separatore/filtro L/R senza che aggiunga deleteri oversampling.
Potrei evitare tutti questi sbattimenti utilizzando schede con altri DAC e che non hanno questa peculiare caratteristica del 1704 ma sono straconvinto della bontà sonica di questo DAC.

Un augurio di Buon Anno a Te e a tutti i Forumers

[marcoc1712]

Marco ,puoi indicarmi il 3d per favore? Seguo con molta discontinuità le discussioni e questo mi deve essere sfuggito.
Nel caso specifico di più DAC finalizzati a multi channel per crossover ( no home theater), personalmente preferirei evitare se possibile il reclocking e il buffer FIFO per motivi di delay non facilmente prevedibili e/o gestibili (come sincronizzare le varie schede?) Inoltre da esperienze fatte con la scheda DAM 1021 che ha sia il buffer FIFO che il reclocker, in alcune situazioni si avevano strani comportamenti silenziando un canale e comunque qualcosa non mi convinceva all'ascolto.
Ciò che mi entusiasma nel progetto di Giovanni è proprio l'estrema semplicità/purezza del flusso dati che viene inviato al 1704, semplicità che in questo caso elimina diverse " colle" mettendolo nelle migliori condizioni di lavoro. A mio parere è più importante cercare di ottimizzare la risposta nel domino del tempo intesa come risposta ai transienti dove i filtri antialea fanno ancora sfracelli piuttosto che ottimizzare il dominio temporale con la ricerca di jitter al femtosecondo o isolamenti galvanici ad ogni costo. I positivi riscontri di Giovanni, che di 1704 penso ne abbia esperienza, stanno a indicare che la strada è quella giusta. Nel mio caso specifico ( spero di utilità anche per altri) stò cercando qualcosa di simile alla JLsounds ma che faccia solo da separatore/filtro L/R senza che aggiunga deleteri oversampling.
Potrei evitare tutti questi sbattimenti utilizzando schede con altri DAC e che non hanno questa peculiare caratteristica del 1704 ma sono straconvinto della bontà sonica di questo DAC.

Un augurio di Buon Anno a Te e a tutti i Forumers

Il thd è questo, trovi al suo interno i diversi link a fonti esterne, compreso il progetto di IAN Canada. Vedrai che tutto nasce dal progetto delFIFO e poi si biforca, facendo nascere la seconda scheda.

...ma se fifo, isolamento e reclocking, esattamente come nel caso della JLSOUND, operano sul flusso in ingresso, come si pone il problema di ritardo e sincronizzazione tra canali? Non credo prorio che la scheda di IAN faccia oversampling o applichi filtri nel modo più assoluto, 'semplicemente' converte il formato del segnale (la sua presentazione in worlds) lasciando del tutto inalterato il contenuto informativo (bit).

Per quanto ne so, nei formati "PCM" devi necessariamente prevedere il 'latching' dei diversi canali, altrimenti vai incontro a problemi di sfasamento, dovuto al fatto che in I2S hai nello stesso frame prima un canale e poi l'altro, mentre i due flussi in uscita devono essere 'contemporanei', quindi devi inserire un ritardo di N (= bit depth/2) tic del bitclock sul primo canale. E' uno dei compiti delle diverse colle logiche, che credo implementi in qualche modo anche la JLSOUND.

Però io non sono certo un esperto e questo punto è essenzialmente quello che sto cercando di capire. Ho promesso di realizzare uno schema a blocchi per capirsi meglio e stimolare gli esperti ad intervenire nell discussione con risposte 'certe', ma lo devo ancora fare... chiedo scusa.

p.s.


AUguri anche a te ed a tutti.

[bigtube]

..................................................... L'utilizzo della BBB (ma non credo sia utile con il fifo idi IAN, Giovanni mi posti il link al progetto?) potrebbe risolvere il problema utilizzando il MCLK del Reclocker di IAN in input, ma - come segnala Paolo - rompendo l'isolamento galvanico.

Ci siamo arenati lì, o meglio, mi sono arenato io.

L'ho trovato qua':
https://www.minidsp.com/forum/opendr...isharc-project
Info sulla scheda ( costicchia ):
MiniDSP miniSHARC DSP Kit Processor Audio 24/96bit 4x8 channel - Audiophonics

[bigtube]

Nel frattempo mi son dato da fare....purtroppo il buon Dario Inserra è scomparso dalla scena....ne ha buon diritto e io non ho voluto aspettare.
Insomma la PCB dell'I/V me la son fatta in casa. Schema alla mano del mio prototipo dopo un po' di combattimento in quanto totalmente novizio
della materia, che peraltro è complessa, con l'aiuto di Fritzing (software open source e gratuito ma che accetta donazioni) ho creato il primo lavoro
che spero possa piacere. Mi ha dato una mano ( crudele ma benefica ) l'amico Ruggero con preziosi consigli.
la scheda misura poco meno di 6 x 5,5 cm, ha due layer (top e bottom) e un piano di massa sul top. Connessioni con l'esterno ovviamente per i 1704
e per l'alimentazione +15V e -15V e infine almeno 3 OUT :
-buffer interno
-buffer esterno ( OPA627 )
-dal TZ (pin 5 844) diretto
Per questioni di spazio e efficienza ho previsto sul layer bottom dei pad per utilizzare smd ( resistenze e condensatori in formato 1206 )
per il corretto decoupling dei pin d'alimentazione con particolare cura per gli 844( the magic ).
Le schede son state testate dal programma con DRC e potrebbero andare in produzione.
Per la bisogna ho gia' creato i file Gerber.
Per fortuna ho catturato anche i Gerber della scheda per i 1704 e potrei mandare in produzione anche quelli.
Queste son le foto del "neonato" :

screen del Top layer con piano di massa spostato (prima foto)
piano di massa sul top (seconda foto )
piano del bottom layer ( con ground maggiorato nell'asse di confluenza)

.

[DacPassion]

Si è defilato nel senso che non produrrà neanche le schede per i 1704?