SD card wav player

[andrea_mori]

Ciao a tutti,

dal momento che non ho esperienza con i uC, sono a chiedervi un suggerimento sull'architettura di un sistema per riprodurre file audio da una SD card. Dico sistema perché trasporto e DAC dovranno essere parte di un sistema globale di riproduzione, e non componenti separati con i rispettivi clock.
In altre parole il sistema dovrà essere in qualche modo sincrono, per minimizzare gli effetti nefasti dovuti al jitter.

In altre parole, il DAC avrà il suo master clock, e dovrà in qualche modo "tirare" i dati dal uC, piuttosto che essere il uC a "spingere" i dati verso il DAC.
Una semplificazione è data dal fatto che dovrò supportare soltanto file wav campionati a 16 bit / 44.1 kHz.
Preferibilmente la sd card dovrà essere formattata FAT32, con supporto fino a 32GB di dimensione.
Ho dato un'occhiata alle varie schede di valutazione disponibili ed avrei optato per la STM32F4 Discovery, più la base board e la scheda LCD, dal momento che vorrei usare il touch screen per gestire la varie funzioni utente, quali navigare tra le cartelle, play, pause, stop, avanti, indietro e via dicendo.

Per quel poco che ho capito, potrei leggere i dati dalla SD e spararli sul bus SPI, che però dovrebbe essere slave, dal momento che il DAC dovrebbe tirare i dati dall'SPI e quindi fornire il clock. Dimenticavo, il master clock del DAC è 11.2896 MHz.
Pensate che sia possibile implementare un'architettura di questo genere?
In caso affermativo, la cpu dovrà lavorare con il clock fornito dalla scheda discovery oppure potrei/dovrei utilizzare il clock molto più preciso e pulito che userò per il DAC?

[deluca]

@andrea_mori,
benvenuto al forum.
trovo il tuo topic abb interessante(mi riservo di avere qualche perplessità sulla modalità di riproduzione da te indicata e l'uso che ne devi fare).

cmq, ti invito a presentarti nella sezione dedicata.

[Leonardo]

Ciao Andrea,

La STM32F4 Discovery ha un micro con DAC incorporato, è inoltre presente un IC sulla board con DAC + Amp di classe D che ti consiglio di usare.

Vuoi realizzare una sorta di lettore MP3 diy?

[andrea_mori]

Ciao Andrea,

La STM32F4 Discovery ha un micro con DAC incorporato, è inoltre presente un IC sulla board con DAC + Amp di classe D che ti consiglio di usare.

Vuoi realizzare una sorta di lettore MP3 diy?

Tutt'altra cosa, vorrei realizzare un lettore di file lossless qualità CD (16 bit / 44.1 kHz) alta fedeltà allo stato dell'arte, quindi il DAC incorporato è da escludere. Il uC ha il solo scopo di leggere i dati dalla SD e renderli disponibili al DAC.
Per quanto riguarda il DAC vorrei lasciare aperte 2 strade: la prima è quella di utilizzare il vecchio (ma a mio parere mai superato in qualità soniche) TDA1541A usando la modalità simultanea offset binary, quindi devo produrre in uscita dal uC i bit seriali dei due canali simultaneamente su due linee separate.
La seconda strada è quella di costruire un DAC discreto R2R, e quindi dovrei produrre in uscita dal micro i bit seriali per alimentare registri a scorrimento tipo 74XX595, che a loro volta interfacceranno la rete R2R parallela dei due canali.
Avendo a disposizione un oscillatore molto preciso, con un rumore di fase bassissimo, per ridurre al minimo il jitter, vorrei fare in modo che i dati venissero estratti dal micro per mezzo del suddetto clock, piuttosto che utilizzare i timing del micro stesso.
Non avendo esperienza con i microcontroller, la mia difficoltà riguarda la definizione dell'architettura del sistema a livello del uC, ad esempio quali porte o bus utilizzare.

[Leonardo]

Il progetto sembra molto carino, pone anche molte sfide di elettronica analogica. Cosa ne dici di presentarti nell'apposita sezione del forum?

Hai già delineato qualche specifica in più del progetto? Diffusori acustici, potenza in uscita dall'amplificatore, tensione di funzionamento del sistema, etc.. etc.. ? Quando parli di Jitter, che scala di grandezza intendi? ms?

Il TDA1541A sembra fuori produzione da un bel pezzo però.. potrebbe costarti molto comprarne uno e sarebbe difficile evitare falsi. Io andrei su IC più recenti, ce ne sono anche in classe A/AB anche se la classe D è molto utilizzata ultimamente.

Se hai un oscillatore molto preciso puoi utilizzarlo per il micro, non devi utilizzare per forza l'oscillatore interno.

Ciao

[andrea_mori]

Scusa l'ignoranza, ma come si accede alla sezione del forum per presentarsi?

Più tardi aggiungerò tutta un'altra serie di specifiche del progetto per renderlo più chiaro, per ora posso aggiungere che quando parlo di jitter intendo ps o addirittura femto secondi.

[Leonardo]

Semplicemente puoi aprire un thread in questa sezione: http://www.delucagiovanni.com/public/phpbb3/viewforum.php?f=19

Non sono un audiofilo ma ha senso parlare di femtosecondi per un segnale audio? Hai il budget per attrezzature idonee a verificare femtosecondi di jitter per questo progetto?

[andrea_mori]

Semplicemente puoi aprire un thread in questa sezione: http://www.delucagiovanni.com/public/phpbb3/viewforum.php?f=19

Non sono un audiofilo ma ha senso parlare di femtosecondi per un segnale audio? Hai il budget per attrezzature idonee a verificare femtosecondi di jitter per questo progetto?

Femto secondi probabilmente no, ma pico secondi sicuramente si.
Uno dei problemi più gravi nella conversione digitale analogica è proprio il jitter.
Considera che l'oscillatore a cui ho accennato è stato misurato da un amico olandese che ha rilevato un rumore di fase di -130dBc a 10 Hz dal carrier, ovvero un jitter RMS di appena 0.4 ps.
Ho la possibilità di accedere ad un Agilent presso un laboratorio del CNR presso l'Università di Pisa per effettuare le misurazioni.
Data la qualità dell'oscillatore, non vorrei compromettere tutto con il lavoro che dovrà fare la CPU.
Per cui, nella mia ignoranza relativamente ai micro, credo di avere due possibilità: la prima è quella di "tirare" i bit dal micro per mezzo del clock fornito dal mio oscillatore, che detterà anche i tempi del DAC.
L'altra potrebbe essere quella di sostituire il clock della cpu sulla scheda Discovery con il mio oscillatore ed utilizzare i contatori/divisori del micro per sincronizzare il DAC. Sulla scheda c'è un cristallo da 8MHz, mentre il mio oscillatore lavora a 11.2896MHz, probabilmente dovrò settare qualcosa di diverso nelle header per far sapere alla cpu che sta lavorando ad una frequenza diversa.

Il mio problema principale prima di avventurarmi in questo progetto è quello di definire la miglior architettura possibile per utilizzare al meglio sia l'oscillatore che il micro.

Ogni consiglio sarà ben gradito.

[Leonardo]

Se hai voglia volevo aprire una parentesi sulla reale necessità di un jitter così basso. Essendo la risposta di fase dei diffusori non sempre perfettamente lineare, l'ambiente di ascolto non perfetto, etc.. è umanamente distinguibile un jitter di 100us da un jitter di 1ps? La registrazione dei CD avviene inoltre con un qualche jitter minimo specificato?

Detto questo se al micro colleghi l'oscillatore di basso jitter (è stato misurato anche a condizioni ambientali variegate?) al micro non dovresti avere problemi, come giustamente hai dedotto il firmware sarà da realizzare tenendo conto della frequenza reale dell'oscillatore.

Tieni presente però una cosa, è molto sconsigliato partire dagli ARM se non hai esperienze pregresse coi micro-controllori, sono abbastanza tosti da utilizzare e meritano molta dedizione, per la sua semplicità in genere consiglio un Arduino per iniziare a prendere dimestichezza anche se non sarà magari utilizzato nel progetto.

[legacy]

Usare un buffer di memoria da cui estrarre dati con un clock ad alta precisione dovrebbe ridurre l’errore di jitter. Per quanto riguarda la MPU vedo due soluzioni

1) usare il tuo oscillatore modi clock source, molte MPU lo permettono
2) dividere la frequenza del tuo oscillatore ed usarla modi trigger interrupt driven, p.e. isr_DAC_out() triggered on external time interrupt

[andrea_mori]

Se hai voglia volevo aprire una parentesi sulla reale necessità di un jitter così basso. Essendo la risposta di fase dei diffusori non sempre perfettamente lineare, l'ambiente di ascolto non perfetto, etc.. è umanamente distinguibile un jitter di 100us da un jitter di 1ps? La registrazione dei CD avviene inoltre con un qualche jitter minimo specificato?

Detto questo se al micro colleghi l'oscillatore di basso jitter (è stato misurato anche a condizioni ambientali variegate?) al micro non dovresti avere problemi, come giustamente hai dedotto il firmware sarà da realizzare tenendo conto della frequenza reale dell'oscillatore.

Tieni presente però una cosa, è molto sconsigliato partire dagli ARM se non hai esperienze pregresse coi micro-controllori, sono abbastanza tosti da utilizzare e meritano molta dedizione, per la sua semplicità in genere consiglio un Arduino per iniziare a prendere dimestichezza anche se non sarà magari utilizzato nel progetto.

Un jitter di 100 us è chiaramente udibile, te lo assicuro, per aver provato vari clock sullo stesso DAC.
Questo è un documento che spiega molto bene le problematiche legate al jitter nei convertitori DA
http://www.tnt-audio.com/clinica/jitter1.html
nell'ultima parte spiega anche chiaramente che oscillatori con jitter di pochi ps diventano pressoché inutili se tutto il sistema non è progettato per sfruttarne al meglio la qualità.

Che è appunto quello che vorrei cercare di fare, evitando di vanificare tutto partendo dal sistema di timing originale del micro, con prestazioni a livello di jitter sicuramente inferiori.

Arduino non è assolutamente adatto allo scopo; so bene che gli ARM sono complessi e sto cercando giusto una serie di indicazioni precise da chi li conosce bene per definire correttamente fin dall'inizio l'architettura da utilizzare.

[andrea_mori]

Usare un buffer di memoria da cui estrarre dati con un clock ad alta precisione dovrebbe ridurre l’errore di jitter. Per quanto riguarda la MPU vedo due soluzioni

1) usare il tuo oscillatore modi clock source, molte MPU lo permettono
2) dividere la frequenza del tuo oscillatore ed usarla modi trigger interrupt driven, p.e. isr_DAC_out() triggered on external time interrupt

Grazie per la risposta, che inizia a chiarirmi la questione.

Stavo in effetti pensando di sostituire l'HSE della Discovery board a 8 MHz con il mio oscillatore di precisione a 11.2896 MHz. Presumo di dover dissaldare il cristallo e un paio di condensatori, ma non ho lo schema e quindi non sono sicuro.
Fatto questo, avrei un clock molto preciso dal quale iniziare.
Detto questo, ho bisogno di un paio di timer precisissimi: il primo è il bit clock del DAC, ovvero il clock con il quale vengono passati i singoli bit al DAC (16 bit per canale in modalità simultanea, 2 linee). Il TDA1541A supporta un bit clock massimo di 6.4 MHZ, quindi devo dividere il master clock per 2.
Il secondo è il sample rate, 44.1 kHz, ossia la frequenza con la quale il dac deve aggiornare, ed in questo caso devo dividere il master clock per 256.
Per ovvi motivi di precisione, questi timer dovrebbero essere gestiti dal preciso oscillatore esterno e non dal PLL della cpu.
A questo punto la domanda: è possibile far lavorare la cpu a frequenza più alta per mezzo del PLL, e nel frattempo utilizzare timer che invece usano il clock esterno?
I timer lavorano in background? Posso far uscire direttamente questi 2 clock su qualche porta (GPIO?) senza alcuna interferenza da parte del lavoro che sta facendo la cpu?

Oltre a queste 2 linee di clock a partire dai timer, ho bisogno di un paio di linee per passare i dati al DAC sincronizzate dal clock a 5.6448 MHz, prodotto dal timer che divide per 2 la frequenza del master clock.
Quali porte dovrei utilizzare?

[legacy]

Spetta, i drift in frequenza non sono dovuti ai circuiti digitali della CPU, nemmeno al suo PLL, sono dovuti primariamente al quarzo esterno o peggio ancora al risuonatore ceramico.

Io farei cosi':
- ti tieni il quarzo o risuonatore che hai gia', al limite setti il PLL per avere una frequenza di clock alta lato MPU
- dividi in hw (2) il tuo oscillatore fino ad avere una frequenza di 44.1 kHz
- agganci questa frequenza di 44.1 kHz ad un interrupt
- nella sua ISR (interrupt service routing) scrivi sul DAC (1)

In questo modo svincoli la CPU dal dover avere un clock precisissimo, il tutto sta in piedi se funge da FIFO, ovvero se leggi i dati dal media molto + velocemente di come li scrivi sul DAC, infischiandotene di eventuali drift lato MPU, tanto fai buffering in ram e sincronizzi il DAC e relativo suo aggiornamento su un clock esterno precisissimo.

(1) devi gestirti un buffer con relativo puntatore
(2) meglio se lo fai con un circuito PLL, in modalità divisore.

[deluca]

Ho qualche dubbio sul come elaborare i molteplici processi e la sincronizzazione perfetta tenendo conto dei tempi di latenza dei vari interrupts provenienti ad esempio dalla richiesta cambio menu display ecc ecc. E' vero che dovresti crearti un buffer tra i dati provenienti dalla sd e il dispositivo di riproduzione, ma il prb rimarrebbe lo stesso.

Secondo me dovresti isolare la gestione ad alto livello(tastiera, display, interfacce usb, sd-card reading) uC based, da quella a basso livello che io realizzerei a partire da una logica programmabile saldamente connessa al dac stereo con oscillatore di precisione compensato in temperatura, se vuoi limitare al minimo gli effetti legati dannosi al bit-streaming jitter.

[legacy]

I timer lavorano in background? Posso far uscire direttamente questi 2 clock su qualche porta (GPIO?) senza alcuna interferenza da parte del lavoro che sta facendo la cpu?

Nelle MPU l'hw dei timer lavora in parallelo alla CPU, di fatto e' un contatore, con a valle un prescaler programmabile, che può generare un interrupt quando va in overflow, sicche' sotto interrupt puoi fare del lavoro sincronizzato all'evento temporale. La ISR deve essere la + breve possibile, ti suggerisco variabili globali e poco/nullo context switch.

[legacy]

Ho qualche dubbio sul come elaborare i molteplici processi e la sincronizzazione perfetta tenendo una logica programmabile saldamente connessa al dac stereo con oscillatore di precisione compensato in temperatura, se vuoi limitare al minimo gli effetti legati dannosi al bit-streaming jitter

In pratica spostare il FIFO fuori dalla CPU, ovvero la cpu aggiorna questa logica quando può (cosi' può badare alle sue faccende, tastiera, LCD, SD card e filesystem), e questa logica aggiorna invece il DAC a cadenza fissa e super precisa.

[deluca]

Infatti questa, allo stato dell'arte, sarebbe la migliore architettura.... suddividere le 2 attività principali:
gestione filesystem con uC e riproduzione audio con FPGA/memoria/DAC

[Leonardo]

Arduino non è assolutamente adatto allo scopo; so bene che gli ARM sono complessi e sto cercando giusto una serie di indicazioni precise da chi li conosce bene per definire correttamente fin dall'inizio l'architettura da utilizzare.

Arduino (che è una dev-board con un micro 8 bit semplice) è adatto allo scopo di imparare alcuni concetti fondamentali dei micro, poi va da se che potrai passare con meno sforzo ad un micro adatto al progetto. Io metterei in conto una fase di learning dei micro-controllori separata dal progetto vero e proprio.

[Leonardo]

Come architettura concordo con Giovanni, micro + logica programmabile sarebbe il massimo. Servono però ancora più skills, hai delle dead-line o esperienze passato con fpga?

..forse però un sistema dual micro potrebbe bastare lo stesso? Micro dedicato al servimento del DAC (con oscillatore preciso) e l'altro micro per file system, etc.. il tutto disaccoppiato con una qualche memoria.

[andrea_mori]

Grazie a tutti per le risposte.

In effetti, inizialmente avevo pensato ad un Artix con ARM integrato oppure ad un Cyclone SE sempre con ARM integrato, ma questo complica ulteriormente il progetto.

Rimanendo all'uso del micro, la prima opzione che avevo valutato era proprio quella di gestire i timing cruciali all'esterno del micro, lasciando il clock originale sulla scheda disco.
Con un paio di 74LVC161 otterrei i 2 clock necessari molto precisi e quasi esenti da jitter a partire dal mio oscillatore. A quel punto si pone il problema della sincronizzazione.
Credo che la lettura dal media sia molto più veloce rispetto all'aggiornamento del DAC, e comunque posso tranquillamente abbassare il bit clock del DAC a 2.8224 MHz o addirittura a 1.4112 MHz senza che il dac ne risenta minimamente.
Provo a ragionarci scrivendo.
All'avvio i due clock dovrebbero essere stoppati (in realtà è un solo contatore dal quale preleverò i due timing, il primo dividendo per 256 ed il secondo dividendo per 2,4 oppure 8), dal momento che non ho ancora dati da fornire al DAC.
Ad un certo punto la cpu avrà accumulato un po' di dati in un buffer. Prima domanda: ho bisogno di gestire RAM esterna oppure sarà sufficiente quella disponibile nel micro?
A questo punto la cpu dovrà abilitare il contatore, il cui clock sarà comunque gestito dall'oscillatore di precisione.
Ad ogni bit clock (5.6, 2.8 o 1.4 MHz) 1 bit per ogni canale, quindi 2 linee, dovrà essere letto dal buffer e passato al DAC. Una volta letti 16 bit per canale il bit clock dovrà essere fermato, oppure dovrò dividere per 16 e usare una frequenza di 705,6 kHz, che rappresenta il bitrate naturale in modalità simultanea (44.1 Khz * 16 bit).
Qui si pone il secondo problema, ovvero come far avanzare i registri di memoria per svuotare il buffer.
Quando il contatore avrà raggiunto 256 il dac sarà abilitato a commutare e si aggiornerà.
Il ciclo riprenderà dall'inizio e si fermerà soltanto quando il buffer sarà vuoto, la cpu dovrà disabilitare il clock al contatore.
Stesso discorso nel caso di interrupt da utente, la cpu dovrà temporaneamente disabilitare il contatore.
Pensate che sia una strada percorribile?

In alternativa dovrei utilizzare i contatori hw partendo però dal clock preciso, ma qualsiasi operazione, pur minima, da effettuare agli interrupt produrrà latenza, a meno che l'operazione si riduca ad alzare (o abbassare)semplicemente il livello di una porta.