Some questions to any experts with ears regarding high fidelity audio...

Should I pursue a PWM 1-bit DAC or a 16/24/32 bit I2S serial stereo DAC?

The 1-bit DAC is noisy and will need to be filtered externally.

The I2S DAC (PCM5102) I am thinking of using needs no such external filtering, and has an excellent SNR, although the pursuit of a hi-res DAC will lead me to a wavetable type setup.


EDIT (9/12/2012): Changed title.

My vote is on the I2S DAC!

How noisy? For some great lessons and demonstrations on the "golden-ears" baloney, watch http://www.youtube.com/watch?v=BYTlN6wjcvQ . It starts out with a lecture at a conference and then goes to demonstrations from quality digital audio equipment in his studio that let him manipulate the exact amounts of different negative characteristics the golden-ears people said were major problems, and you can see if it is or not. In one part, he searched for the most offensive noise he could find, and superimposed in on a fine string quartet performance, and you couldn't hear it at all until it was only about 9 bits down. On my less-than-ideal PC speakers on the desk, I couldn't hear it until it was 7 bits down.

I'm sure you could get away with alot of noise listening to desktop speakers.
I mean to make this so you can play it through a higher end system and it will be enjoyable to listen to.

One of my ideas is to have 6 or more DAC's, these things are only $6 each, mix there outputs together and resample them, and then repeat the process n-times. Still looking for a decent ADC.

The idea is solidifying.
3 stereo DAC's based on the IC previously mentioned. I really don't prefer serial method of data transfer for high speed data, but I guess this will be a learning experience. Each dual DAC will have a dedicated asynchronous SRAM. I knew this from the beginning, but what the market has in stock determines a design. At one point I was considering dual port (4K, 8K, 16Kx16) asynch. SRAM but the speed was limited from 15ns to 25ns. Too slow, for a wavetable that needs to at least approach 20kHz. Would've been cool to update the wave pattern while listening to the changes at the same time.
So, I found a single port 32Kx16 10ns device for under $3ea. That would leave 16Kx16 for each channel of the 5102DAC. For a 100MHz counter and SRAM, in order to reach 20kHz, the max wavetable size is 5Kx16. not too bad. For 15kHz, 6.7Kx16 wavetable. For 12kHz, 8Kx16...
The only part I don't like, as I said before, is the serial data has to be presented to the DAC's. I've not figured out if they can go as fast as I need them too yet...

As far as the controller FPGA, I am looking at another Spartan 6 144-pin. Or, if I need less pins the Spartan 3E series at 100-pin. I've found out the Spartan 3E is almost as capable as the Spartan 6, minus the PLL's. The devboard design fit just as nicely into the Spartan 3E XC3S500E. And they come in packages from 100 pins to 208 pins.

Still looking for a decent high speed 16-bit parallel ADC...

Um, why so many samples? 20kHz x 5K samples makes for a sample rate of 100Msps, and the first harmonic distortion products are at 99.98MHz and 100.02MHz (not kHz). Even with only 8 samples per cycle at 20kHz (ie, 160ksps), the first harmonic distortion products are at 140kHz and 180kHz, way, way beyond the hearing range. The bigger problem would be jitter (producing noise when multiple high frequencies go through at once), not a lack of sampling speed. Holding the jitter down is often done with PLL clock stabilization in the DAC. Common CD audio quality is around 48ksps.

I had to calculate some of this stuff when I made the automated test equipment and synthesize sine waves from wave tables and figure out how many samples per second I needed and what filtering was needed, if any. It turns out that the answers were a lot easier to deal with than I anticipated.

Thanks for responding Garth.
The limiting factor is the access speed of the SRAM. So, with 10ns access times, 100MHz is the fastest the counters can run the address lines to the wavetable RAMs to output their data to the DACs. Divide that by 20kHz, and you have the biggest section of RAM you can store a waveform, if you want to go all the way to 20kHz...
I would like to have a high definition wave. In the beginning stages of a "sound effect" I am picturing a simple sin wave. That sin wave will be represented in those 5K samples. Seems like overkill at first... Then picture the other 2 DACs outputting the sin wave at different freq's. Room in that 5K window now starts to get tight, especially when you sum those and resample, then re-input in back through all 3 DACs and resample again.

If you're looking up several waves at once, then yes, it will increase the memory's speed requirement. There's still no point in sampling at more than 48ksps or 96ksps though. You can have a 5K-point wave fom so it's really clean at the low end of the hearing range at 96ksps sampling speed, but then when you get to higher frequencies, you just don't use all the samples. There are digital signal generator ICs that use a phase accumulator with a lot more bits than are required to address every available sample in the table. At the lowest frequencies, if the table isn't big enough to give a new value for every sample, samples will get repeated until it's time for the next value. At high frequencies where the sampling rate is too low to hit every value in the table quickly enough, samples get skipped.

I wish I could find a good diagram to post. One IC I remember seeing had a sine wave in ROM, 256 8-bit values. The phase accumulator register was 16-bit, IIRC. Let's say you wanted to sample at 65,536sps (2^16) for the sake of discussion. So if you told it to add only 1 to the 16-bit accumulator at every sample time, it would take 256 of these to get to the next position in the table and feed it to the 8-bit DAC, and with 256 positions in the table, it would take 65,536 sample times to get through it, and you'd have a 1Hz output. The high 8 bits of the 16-bit accumulator register go to the 8 address lines of the 256-byte waveform ROM.

256Hz sine-wave output would be the fastest you could go and use each single value in the table exactly once per sine wave cycle. The value you tell it to add to the accumulator with every sample is 256. To double the sine wave output frequency to 512Hz, you tell it to add 512, which results in every other table entry getting skipped, and only 128 values get fed to the DAC in each sine-wave cycle.

At 16,384kHz you would only be using four values in the table, taking large steps of adding 16,384 to the phase accumulator register, 65,536 times per second.

As you can see, the output frequency is proportional to the input number, and in the case above, exactly the same, with 1Hz resolution. Changing the frequency (which you do by changing the step size) does not result in any phase discontinuities. The wave table can contain any arbitrary waveform you wish of course. For high-quality audio, you would probably want more than 256 positions in the table (for reasons of the jitter this method produces) and more than 8 bits each. There's still no need for 100Msps (or even 1Msps) under any conditions though.

Agree with Garth. If you're listening to a 20 kHz tone (ignoring the fact that you can't even hear it, unless you're much younger than I think , the waveform doesn't matter anymore. A square wave sounds the same as a sine wave.

A CD uses a 44.1kHz sampling frequency and 16 bit samples, and that's plenty.

As far as wavetables and memories, for each wave, you'll need a maximum of one memory lookup per sample. Using 100 MHz * 16 bit SRAM, and a 44.1 kHz sampling rate. You could play a total of 2267 arbitrary waves, on all channels combined. at CD quality. I think that should be plenty. If you want to improve the sound quality, you could even interpolate and double the sample rate, without performing more memory lookups. Of course, if you want to update the wave table at the same time as playing the sounds, you have to reserve some memory bandwidth for memory writes.

Of course, the FPGA also has built-in block RAMs that can be used to hold common waveforms such as sine waves, and because of the higher internal speed, and dual access, you can even create more simultaneous sine waves. Other common waveforms, such as sawtooth, square and triangular can all be created inside the FPGA on the fly, without any memory.

Another option is to use SDRAM. This allows much more space, but you'll have to use a bunch of block RAMs as a cache.

CD Quality is good enough, I agree...

Ok, I understand about skipping samples to increase the frequency, and the higher the frequency the less likely the ear can tell whether it's a sine or square wave, so it makes sense to skip samples in the wave table...

Unfortunately using a FPGA block rams for wavetables won't work because they can't be changed like I would like to do. SDRAMs are in the future for when writing data from the ADC...

So I may be able to use some slower 25-55ns dual port asynchronous ram after all. They are abit expensive, and large 100-pin QFPs. The layout will be a real challenge, especially a modular layout like I will try to do...

How big of a wavetable is considered good enough? 4K, 8K, 16K?

My idea would be to hook up the I2S DAC (or any other DAC) to the FPGA, and hook up your SRAM to the FPGA as well.

The FPGA generates 44.1 kHz samples (or any other rate) and sends them to the audio DAC. That means that the FPGA needs to present a single new sample every 22.7 microseconds (per channel, so two samples for stereo).

This means that the FPGA has 22.7 microseconds available to figure out what the value of that sample is. If you wanted to mix 100 different random waveforms, that means it would read 100 samples from the RAM, multiply each of them with a volume, and add them all up. At the end of the 22.7 us sample, send the result to the DAC.

Reading 100 samples from 10 ns SRAM only takes 1 microsecond, so the remainder of the 21.7 microseconds, the SRAM is idle, and you can provide a path from the CPU to the SRAM, so it can read/write the wavetables.

If you hook up the DAC to the FPGA, the FPGA can also use internal block RAMs to store the samples (or use as a cache for external memory). Another idea would be to use an external serial flash, so you can keep a large number of waves for easy access.

I pulled out some graphs I printed from FFTs on sine waves with various numbers of 8-bit steps back when I was trying to see how much resolution I needed for the automated test equipment in 1990. Here's what I'm seeing. (I'm not suggesting you should go with so few steps for high-quality audio, but it does show that you probably don't need nearly as many steps as one might think.)

• with only 8 steps, the first major harmonic distortion products are the 7th and 9th harmonics which are down about 17dB from the fundamental. (The 7th and 9th harmonics of 3kHz are out of the hearing range.)
• with 16 steps, the first major harmonic distortion products are the 15th & 17th harmonics which are about 25dB below the fundamental. (These harmonics of 1.5kHz are outside the hearing range.) The hottest harmonic below that was the 7th at about 55dB below the fundamental.
• with 32 steps, the first major harmonic distortion products are the 31st and 33rd harmonics which are about 30dB below the fundamental. (These harmonics of 650Hz are outside the hearing range.) The hottest harmonic below that was the 5th also at about 55dB below the fundamental.
• With 64 steps, the first major harmonic distortion products are the 63rd and 65th harmonics which are about 36dB below the fundamental. (These harmonics of 325Hz are outside the hearing range.) The hottest harmonic below that was the 13th at about 63dB below the fundamental. The next major harmonic distortion products are the 127th & 129th harmonics at about 42dB below the fundamental. The hottest between the 65th and 127th is about 68dB below the fundamental.

I didn't keep the numbers, only the low-resolution graphs which I'm trying to eyeball.

You'll want the most points of course for the lowest frequencies; but at 1024 steps, the first major harmonic distortion products of 20Hz will be above the hearing range, so 1K or 2K points, along with the lower distortion products within the hearing range would probably be plenty for them. You could do some more analysis with something like MatLab. There's a lot I can do with my workbench computer and actually try it and listen too, but it all takes time. If you used the same phase accumulator and table for all frequencies, 1K points at 20Hz would only turn into 1 point at 20kHz which obviously is not enough. You'll have to have more than 2 points. A 4K table would probably be adequate. At that number of points I'm sure you'll want more than 8 bits so the low number of bits doesn't become the bottleneck. Follow the DAC with a 20kHz brick-wall filter. I have also experimented with linear interpolation between points to reduce the anti-alias filter requirements. It helps a lot, artificially oversampling at 2x or 4x.

Thanks for digging out that info Garth!
Looks like there will be access time left for higher sampling speeds than 44.1kHz. Arlet, good ideas. I should've thought of the FLASH!... So I can forget the dual port RAMs. Whew! Those dual port ASRAMs are lots of money and use lots of real estate.

That's 2 cores now (not including a 2nd 65Org16 core), SPI for Flash, and I2S for DAC. This time I will use a dedicated CPLD for those. HMMM, I rethinking that now that I found a 100-pin Spartan 3E. I may have no use for CPLDS at all...

I've found 32Kx16 SRAMs 10ns for $3.50ea. That would give 16Kx16 for each channel per DAC.

Also, in the I2C spec they provide a schematic for the transmitter which I can use, if the I2S core I've chosen doesn't work out for some reason. I still need to look into the detail. I think there was mention of it interfacing to a buffer memory.

I'm going to see if I can pick out a good 16-bit parallel ADC tonight when I get home. I saw a nice 50MSPS 16-bit one, but it had differential inputs and according to the app notes, some circuitry had to be added for non-differential signals. I would like to use 1 32MBx16 SDRAM for waveform storage from the ADC.

After a very lengthy search I narrowed it down to 2 companies: Maxim, and TI/Burr-Brown. Linear Technologies had some 100+MSPS parallel ADC's, but all had differential inputs.

The MAX1165 is a 165ksps, single input, 16-bit parallel interface, ADC for $20.

All around a very nice looking IC in 28-pin TSSOP. These parallel ADC's are sorta tough to come by nowadays. Alot of serial out there. But the serial IC's also come with alot of extras, like the one below has a built in high pass filter and programmable gain adjust.

The PCM1851a is a 96kHz, 24-bit, 6x2input MUX, I2S audio interface & I2C register interface, ADC for $7.38. It has an option for 16-bit word lengths. This IC comes in 32-pin QFP.

Both require +3.3V digital and +5V analog supplies.

Right now I am leaning towards the TI unit.

So far all IC's fit onto the 3.5"x2.8" board. 3 20-pin SSOP stereo DACs, 3 44-pin TSSOP II 32Kx16 SRAMs, 100-pin QFP FPGA, 32-pin QFP ADC, 54-pin TSSOP II 16Mx16 SDRAM, and 8-pin SOIC SPI FLASH.
I was thinking even though it will be another 4-layer board, to have the digital components on the topside, and analog components on the bottom side.

Soon, this board will have to go on the back burner, because the V1.1 devboards will be coming in. Maybe I will have another week to mull things over for this sound board. Like exactly how to set up the interface to the mainboard. The devboard has so much room left in the memory map, I could multiplex the soundboard memory and access it directly at certain times, or have a 2 register (command/data) access.

I expect that's to make it easier to keep digital noise out of the analog inputs. Can one side be run right near ground (like a few mv above and below)?

Our experience with TI has not been good as far as engineering support and related services. If you can just buy a part from Digi-Key and get it all going by yourself that shouldn't be an issue, as no company is going to want to put time into someone who only buys $100 of product; but when you're designing a commercial product it's different.