Newsgroup: it.hobby.elettronica.digitale
Titolo: Ancora un dubbio su DAC audio

Ciao a tutti,
oggi sono più ottuso del solito e vorrei chiedervi conferma prima di 
prendere abbagli...
Prendiamo un qualunque DAC audio, es:
http://www.cirrus.com/en/pubs/proDatasheet/CS4349_F1.pdf
Lo stream audio viene trasmesso tramite i segnali LRCK, SCLK, SDIN. Il 
primo indica quale sezione (left, right) si sta in quel momento 
aggiornando. E' un clock a tutti gli effetti e il suo periodo è 
esattamente 1/fs.
Il clock dei dati SCLK non è in alcun modo legato a LRCK, giusto?
Infatti nel datasheet leggo che può arrivare fino a 55 MHz. Quindi io 
2*44100 volte al secondo inverto lo stato di LRCK e quando voglio 
all'interno del semiperiodo invio i miei 16 bit di dati. E' corretto?
Curiosità: a pagina 13 del datasheet in alto è riportato un "RMCK output 
frequency" che non ho capito cosa sia. Facendo una ricerca per RMCK nel 
pdf mi trova solo quelle due righe....
Grazie!
Marco / iw2nzm

 all'interno del semiperiodo invio i miei 16 bit di dati. E' corretto?
In pratica, LRCK è un segnale di latch che carica il dato shiftato nel
registro a scorrimento interno nel DAC del giusto canale.
Agisce sui fronti: di salita per un canale, di discesa per l'altro.
Credo proprio che sia indipendente dal clock SCLK, per quanto, in
genere, ne è ottenuto tramite una divisione.
Quindi, prima puoi caricare con comodo il dato con SCLK e SDIN, poi
latchi il tutto con LRCK in modo da avere una perfetta cadenza di
44100 sample al sec (x2 perché stereo).


 44100 sample al sec (x2 perché stereo).
Ok, allora avevo visto giusto. Non capisco però perché nel diagramma 
dell'interfaccia audio seriale (di tutti i DAC audio) sono mostrati 
anche i cicli di clock non usati. Voglio dire una volta che ho trasmesso 
i miei 16 bit potrò bene smettere di fornire l'SCLK spero!
Non so... mi sembra più complesso del dovuto aggiornare un DAC *audio*. 
Ne ho usati molti general purpose e non facevano tante storie :)
Solo perché hanno i filtri interni dedicati ad applicazioni audio 
complicano così il protocollo? ^__^
Ciao e grazie come sempre!
Marco / iw2nzm


wrote:

Hai scelto un DAC piuttosto complesso.
SLCK deve essere sempre presente perché serve all'interpolatore per
generare i samples tra due stream di dati.
Mi spiego meglio:
quando invii due campionamenti consecutivi, all'uscita ti ritrovi con
2, 4, 8, od anche 16 valori interpolati dal DAC.
Per farceli stare, ha bisogno di un clock parimenti più alto e sempre
presente.
Infatti, si parla anche di 55 MHz.
Va da sè, che SCLK è sincronizzato in qualche modo con LRCK.
Infatti, una volta inviati i bit giustificati a dx o a sx, il clock
non deve cessare.
L'unico modo che puoi usare efficacemente con l'SPI di un micro è
quello senza oversample, ammesso che (e non credo sia il caso degli
AVR) non ti sia possibile far uscire sempre un clock e montare uno
stream su di esso potendolo sincronizzare con l'LRCK.
A pag.18 (Sample Rate Auto-Detect) trovi lo spiegone forse troppo
sintetico.
Danno per scontate cose che non lo sono.
Sarebbe bene trovare un DAC con clock ben separati: uno per
l'immissione dei dati e l'altro per l'oversample.
A complicare il tutto, nel chip che hai indicato ci sono funzionalità
per multi-DAC.
Bello, ma forse un po' esagerato.
Piccio.

 Bello, ma forse un po' esagerato.
Concordo :)
Io ero orientato a un normalissimo DAC a 16 bit tipo il DAC8532 della TI 
o qualsiasi altro in cui hai solo una SPI: carichi i dati e al termine 
della trasmissione i latch di uscita sono aggiornati.
Ma su i.h.e. mi han detto che per applicazioni audio sono vivamente 
consigliati i DAC audio appunto. Che però complicano di molto l'hardware 
e il firmware.
Non avendo mai potuto confrontare un PCM 44100 / 16 bit / stereo 
generato da un DAC general purpose e uno audio non ho idea se vale 
davvero complicarmi la vita.
L'applicazione è riprodurre file wave (effetti sonori o brevi brani 
musicali) da una SD card su un paio di casse da 25W.
Tu che faresti?
Marco / iw2nzm


wrote:

Per il pionerismo che muove le mie gesta, sarei contento anche se solo
scoreggiasse!  :-)
Userei anche solo i PWM per rigenerare l'audio.
Se devo sorprendere con qualcosa di musicalmente evoluto ed inusuale,
sarei costretto ad utilizzare convertitori MP3 bell'e'pronti, ma
"there is not taste" (non c'é gusto).
Molte sorgenti audio digitale escono già con i segnali condizionati
per il DAC.
Sinceramente non ricordo quando utilizzai il TDA1311A in abbinamento
al AT8515 che tipo di qualità ottenni.
Se vuoi ti mando il progetto dal CAD con software.
Leggevo da EPROM esterne un file WAV direttamente sparato dentro e lo
riproducevo.
Il tutto con l'SPI, ma le mie ultime esperienze (generazione di
segnale video con SPI) mi hanno fatto intravedere dei limiti.
Piccio.

 per il DAC.
Qui la "sorgente audio digitale" è il file che sputa fuori audacity dopo 
aver registrato da un cd o dal microfono...
Comunque mi sa che vado di DAC GP... non credo valga la pena incasinarsi 
troppo. Anche perché avrò già il bel da fare per leggere i dati PCM 
dalla SD e sputarli sulla SPI del DAC con un AVR da 20 MIPS.
Orpo, troppe sigle in due righe.
Ciao!
Marco / iw2nzm