Controller to read wav files from SD CARD

[andrea_mori 0]

I need a little help to choose the right device.

 

I would build a digital audio player with the following characteristics:

- it should read data from SD card only (up to 32GB size)

- SD card will be formatted FAT32

- the root of SD card will contain folders only (named as album title/artist)

- no subfolders will be allowed on SD card

- each SD card folder will contain wav files only (named as title track)

- only 16 bit / 44.1 kHz wav files will be allowed (CD quality)

- music data should be read and managed synchronously

- 6 buttons have to be managed: previous track, next track, play/pause, stop, return and enter to navigate the folders (no buttons using touch screen display)

- TFT display will be managed to show album/artist, title track, time elapsed and so on (replace the buttons if touch)

- data output (16 bit serial X 2 channels) should feed a r-2r discrete ladder DAC

- 74XX595 logic will split the serial data to parallel to feed the ladder network

- master clock should be 11.2896 MHz, shared from both DAC logic and uC, to avoid any divider

- every time a single bit is ready, uC should enable the 595 to store it (595 clock enabled from uC in sync with master clock)

- every time 16 bit for 2 channels are read, uC in sync with master clock should enable the 595s to output parallel data to update the ladder network

 

Practically, file system and wav headers aside, using 11.2896 MHz master clock for all the system, I have to start reading 4 bytes from the SD

card (1 left + 1 right samples), then I should pass each single bit synchronously to 4 * 74XX595.

The clock of the 595 to store data should be enabled either from the master clock and the uC (data ready to store).

After the 32th bit is stored in the last 595, uC should enable the master clock to tell all the 595s to output parallel data to update the ladder network.

Finally the clock of all the 595s should be stopped for 224 cycles, and no data should be read from the SD card.

Now the program has to read next 4 bytes, until the end of the wav file.

In the meantime I have to manage the TFT display and interrupt from the user buttons or touch screen

 

What device do you suggest to do all the above job? STM32 M4?

Can I run all the system at the same master clock (11.2896 MHz)?

Can I read and manage data synchronously from the SD card?

.

Thanks

Andrea

[Kartman 0]

First up, trying to build a 16 bit dac from resistors is probably not a good idea - why? For 16 bit precision you're going to need very precise resistors. Ten bit is achievable, 16 bit near impossible. Real 16 bit dacs use different techniques to achieve the resolution. Considering audio dacs are cheap why not use one? You need to generate i2s protocol.

[andrea_mori 0]

I'm planning to use 0.02% or 0.01% resistors, so I can easily reach 16 bit precision.

Modern bitstream DAC are surely cheaper, but IMHO they sound bad.

I already own a SD card player that outputs I2S, used to feed a TDA1541A, an old DAC that sounds much better than the modern DAC.

Now I would build an integrated system, to minimize the jitter, so I'm thinking to a uC feeding a discrete R2R DAC, using a very low phase noise master clock (-130dBc@10Hz from the carrier).

[Kartman 0]

I'm sorry to sound negative, but even with 0.01% resistors the hc595s arent up to the task. You also will have thermal issues - keeping all your precision resistors isothermal will be fun. There's a number of fundamental issues you're up against. I really don't think you'll achieve 16 bits of resolution. And how will you be able to measure it?

[Kartman 0]

As for reading the data synchronously from the sd card - forget it. You can only expect to read the data from the sdcard asynchronously and use a circular buffer to negotiate the sync output rate from the async input data. Even cd players buffer the data.

[andrea_mori 0]

I'm sorry to sound negative, but even with 0.01% resistors the hc595s arent up to the task. You also will have thermal issues - keeping all your precision resistors isothermal will be fun. There's a number of fundamental issues you're up against. I really don't think you'll achieve 16 bits of resolution. And how will you be able to measure it?

The resistors I'm planning to use are ±0.01%, 0.05ppm/°C, so I don't think to have any issue of precision and thermal stability. Also, thermal drift affects the conversion in long time, that's not a great issue.

I'll use the 74LVC595, fast enough to switch at 352 kHz, but I'll don't use it to drive the ladder network, because of its relatively high RDSon. The ladder network will be drived by dual mosfet such as FDS8958 or so.

I don't own the gears to measure the final precision, but on the sheet I don't see great problems. The final judge will be the ears.

I'm enough sure about the digital to analog conversion, but I'm very confused about the uC.

A system that don't run synchronously will be affected by some jitter, that's the great issue. That's the reason I would run alla the system synchronous, reading 1 bit from the SD card and feeding the DAC in the same clock cycle.

[andrea_mori 0]

As for reading the data synchronously from the sd card - forget it. You can only expect to read the data from the sdcard asynchronously and use a circular buffer to negotiate the sync output rate from the async input data. Even cd players buffer the data.

As I said above the great issue in digital to analog conversion is the jitter, when the system doesn't run totally synchronized.

Do you say the only way to read data from SD card is using a FIFO?

Do you think it's a "bit perfect" way?

I could mask the clock of the 595s, storing each incoming bit only when the uC enables to do that.

[Kartman 0]

Well, I think you'll learn some lessons along the way. Just the thermocouple effects will equate to a couple of bits of resolution - unless you run a higher voltage, say 10 volts.

I think you really don't understand how the sd card works. First up, whilst the clocking of the bits is synchronous, the reading of the sector is not necessarily so - it has an internal controller that tells you when it's ready. Since the memory technology requires error detection and correction, the controller may take a variable amount of time to do this. Next is the file system - if you choose to use FAT32 file system, you need to read the FAT table for each cluster, so this means you need to do extra reads and computation to find out the next sector to read in the file. As such, this is not a problem - you buffer the data in memory (circular buffer). As for clocking out the data to the shift registers, this does not have to be synchronous - you can clock your 32 bits at any speed you like - as long as it happens within the sample period. The sample clock is the critical one. As to what processor you choose - well there's many. Reading a sd card and pumping the bits out the spi port is quite easy. A cheap TIVA board would do this and you could use Energia to program it.

[Kartman 0]

I did a bit of Googling -

http://www.diyaudio.com/forums/digital-line-level/206258-diy-discrete-r-2r-ladder-dac-serial-data-demultiplexing.html

 

seems I wasn't far from the mark.

 

 

Besides, if you're worried about the sound - everyone knows that digital is crap - you need an expensive turntable and a valve amplifier with oxygen free copper wires facing towards Mecca.

 

Other boards might be the STM32F429 disco - it has a display on it already. I haven't read enough of the datasheet to see if you could use the 11.xxx MHz source as a clock - you might need to divide it by 2 and the STM32 internal PLL will multiply it up to 100+MHz for the cpu. 

 

Exactly how will you generate the 11.xx MHz with low phase jitter? The DAC is going to be so poor in performance that phase noise will be the least of your problems.

As I said before - the only critical timing is the latch for the dac output - as long as everything gets the data out in time, it doesn't have to be synchronous. 

[andrea_mori 0]

I did a bit of Googling -

http://www.diyaudio.com/forums/digital-line-level/206258-diy-discrete-r-2r-ladder-dac-serial-data-demultiplexing.html

 

seems I wasn't far from the mark.

 

 

Besides, if you're worried about the sound - everyone knows that digital is crap - you need an expensive turntable and a valve amplifier with oxygen free copper wires facing towards Mecca.

 

Other boards might be the STM32F429 disco - it has a display on it already. I haven't read enough of the datasheet to see if you could use the 11.xxx MHz source as a clock - you might need to divide it by 2 and the STM32 internal PLL will multiply it up to 100+MHz for the cpu. 

 

Exactly how will you generate the 11.xx MHz with low phase jitter? The DAC is going to be so poor in performance that phase noise will be the least of your problems.

As I said before - the only critical timing is the latch for the dac output - as long as everything gets the data out in time, it doesn't have to be synchronous.

Thanks for the tips.

 

Another link:

http://www.diyaudio.com/forums/vendors-bazaar/259488-reference-dac-module-discrete-r-2r-sign-magnitude-24-bit-384-khz-14.html

 

Glitching aside, I would use 2K/1K or 1K/500R resistors and around 6V for the ladder, to get at least 2V rms at the output, to drive directly an ampli without any buffer. The DAC will be voltage output.

 

Maybe I'm wrong, but I'm not much worried about the R2R linearity, rather I'm worried about the jitter.

I thought to use an STM32F407 or 429 Discovery, with Base board and LCD expansion. I don't know if I can use my external master clock with the Discovery board.

The master clock is a Clapp crystal oscillator with a single fet and a 74xx04 as the squarer. The crystal is a custom fundamental AT-cut heavily polished (ESR less than 7 ohm, Q better than 150K).

 

A question: using SPI to pump out the bits from the uC, do you think can I slave the uC, so the DAC will act as the master for SPI?

 

Andrea

[Kartman 0]

Phase jitter is the least of your worries. If you were using a pll to multiply or divide your frequencies, then yes, phase jitter is a concern. As an engineer, one has to qualify and quantify - what is the problem and how big is it. So what is the phase jitter on a standard crystal oscillator? How does this relate to your phase noise spec? Since you cant measure it, be sure not to chase ghosts. In the link you gave there is the argument between the golden ear brigade and engineers. This is akin to a religious argument. The reality is that you want to reproduce the original analog signal as faithfully as possible. To do this you need to mirror the digitising process. Unfortunately they didn't use discrete dacs to digitise the signal and they did use filters and sample and holds.

What we do know is your discrete dac will glitch - and it is easy to measure. Nothing in this world is perfect - even though your 595's are all clocked the same - the outputs wont all change at the same time. This is why you need a sample and hold. You also need a reconstruction filter to get rid of the discrete steps in the output. These steps give you audible artifacts that are easy to hear and measure - even with a PC sound card spectrum analyser. No buffer on the output of the dac! What about the impedance of the amplifier? The load presented will vary with frequency thus causing more problems.

 

So back to your specific question - you can slave the spi to and external clock, but how would you synchronise the data to the 595s? I think it would be much easier to run the cpu off your crystal oscillator. The cpu has timers that can divide the clock and generate synchronous signals. Besides, the stm32 silicon is faster than the 595 silicon. I've yet to read the stm32f429 datasheet yet - my disco board will turn up tomorrow.

 

My advice is to work with smaller challenges - prioritise your problems and don't try to make the whole thing in one go- otherwise you'll go around in circles. This is complex stuff - even for experienced people.

[andrea_mori 0]

Thanks again for the reply.

About my last link: not all are audio fanatic and integralist, Scott Wurcer has an engeneer approach, not religious, he is the designer of the AD797 in Analog Devices.

 

This is a commercial DAC using R2R ladder

http://www.totaldac.com/D1-single-eng.htm

 

The crystal oscillator was measured with a R&D FSUP by a dutch guy, attached image.

 

About the glitch: FDS8958 has relatively high input capacitance. Could that help to reduce the glitch, smoothing the transiction?

 

The output impedance of a ladder network should be equal to R, in my case 1K or 500 ohm. Do you think I'll have problem to adapt the amplifier input impedance?

 

But you are absolutely right: step by step, one problem at a time.

I have never worked with a uC, so this is my first problem to understand what is the best way to do the job I described. Then I could use anyway a monolithic DAC, maybe the old TDA1541A, that accepts also simultaneus mode offset binary data.

So you suggest to use the crappy oscillator of the disco board for the cpu, but how can I synchronize with DAC running with a different bit clock?

Best way, IMHO, is to place the master clock as close as possible to the DAC BCK and then sync back the source, the uC in this case. Is that possible using SPI or so?

I found some libraries to read data from SD card, SDIO or SPI interface, so I'm confused. What interface do you suggest? When you said pumping out "pumping the bits out the spi port" do you mean also access the card via the SPI bus?

 

Thanks

Andrea

[andrea_mori 0]

What I meant is that my first problem is to define the right architecture of the system, since I have no experience with uC.

Dac choice aside, monolithic or discrete, I would design a system rather than a dac or an SD card transport. The reason is that I'm worried about the jitter of an asynchronous system, where transport and Dac are different devices with their own master clock.

SO, I would place the master clock of the entire system close to the DAC.

In other words, I would pull data from the uC output (SPI?), rather than push the data from the uC.

In this way I have a precise clock right to the DAC, and I'm sure each bit is latched correctly.

Using 11.2896 MHz master clock, the DAC should pull the bits at that frequency from the uC, then when 32 bits are latched I have to tell the DAC to update (44.1 kHz, that means WS for I2S and LRCK fro simultaneous mode).

[Kartman 0]

I think you misunderstand how the hc595 works. You can clock the bits in at any rate as long as it is faster than the update rate. The outputs do not change until you toggle the output clock. The output clock is the critical one. Therefore the processor can be the source of the bit clock. As i've said before - you can probably feed your low jitter oscillator to clock the cpu. The cpu timers can divide the clock to generate the 44.1kHz output clock. This is your master clock divided by 256. So putting your master clock close to the dac is of little consequence - you still need to divide it down by some method - be it a hc4040 ic or a cpu timer peripheral.

 

The stm32f429 has a sdio interface - this is much faster than using the spi for the sdcard. Even so, many cpus have multiple spi ports these days, so you would have separate spi for sd card and dac.

 

Mosfets have gate capacitance and many of their parameters are temperature dependent. It won't help the glitching. Linearity (actually monotonicity) is the critical performance parameter of a dac - if it has poor performance in this regard, it will introduce significant distortion and artifacts to the sound. I think you've got a bit of learning ahead.

 

 

Funnily enough, i was fixing a 90's digital synth with a tda1541 dac tonight.

[andrea_mori 0]

The TDA1541A is a difficult beast, but IMHO it's the best sounding DAC ever built.

My reference is a Naim Audio CD3, it sounds wonderful, not very far from vinyl.

 

As I said above, I have two options: the discrete dac or the 1541.

In the first case, I have to feed the 595s input, as you said I could use the cpu clock, and then I have to clock the 595s to output parallel data every 256 master clock cycle.

In the second case, using OB simultaneous mode, I should split data for each channel to feed simultaneously the DAC, the bit clock could be generated from the cpu, then I should provide the clock at 44.1 kHz to update the DAC. Not sure if I have to stop the bit clock of the dac after the samples are latched. If I remember correctly the TDA discards itself data exceeding 16 bit.

 

So, back to the uC, do you suggest to use SDIO to read data from sd and SPI to feed the dac, or what else?