Let's build a great and proper (okay I will settle for good), OS DAC

[alvaius]

*** THE POINT OF THIS THREAD IS TO GENERATE DISCUSSION AND HOPEFULLY A DESIGN FOR A GOOD OVERSAMPLING DAC ***

What will not be tolerated in this thread:
- Any discussion of non-os DACS. The point of this thread is to develop a "proper" OS DAC. The merits of os and non-os have lots of other threads on diy, this is NOT the place for them.

That said:

It seems there is a need for a "proper" OS DAC to be implemented and tried out. By "proper", I mean one where we have complete control over the digital and analog domain, i.e. we know exactly what is going on at all times, what filters are being used, etc.

To that end, I am proposing development of a DAC using the ADSP-21161 DSP and the PCM1704 DAC. Why these parts? The 21161 DSP can be used as a 32 bit or floating point DSP, it has rich audio ports, it is cheap, and relatively powerful. The PCM1704 is chosen because it can handle a 32x oversampled 44.1KHz audio stream. I would even consider the PCM1702 as it can do 64x.

At this point, I am not sure whether we should implement minimum phase FIR filters for oversampling, or use IIR filters with higher order hold approximations. Even with the 21161, we may be limited in the number of FIR TAPS we can have at 32x or 64x oversampling. This will not be an issue with IIR filters. For IIR, we will stick to Bessel implementations to avoid ringing. Perhaps, a combination of IIR and FIR is in order?

Of course, if we develop a flexible platform, people can do whatever they want with it.

High quality clocking of course will be essential and the oversampled IIS outputs of the DSP will be reclocked before the DAC.

I would like to investigate adding a RAM buffer to completely eliminate PLL clock issues. We could run the output slightly slower than the input (trust me, you would never know). This would lower jitter to the limits of our clock source.

IV convertors of course will be the choice of the individual implementors.


Do I have any takers??

Alvaius

[hifi]

The third try, or Revenge of the PCM1704


Check this thread..

[ultranalog]

Opening a can of worms here:

Why multibit and not sigma/delta?

Remco

[Peter Daniel]

Originally posted by hifi
The third try, or Revenge of the PCM1704


Check this thread..

Obviously you didn't check it. It looks like the current one is an alternate thread (for some reasons).

[alvaius]

I did check that thread. Actually I have a few replies in it.

I suggested to the poster that he use a DSP. He has no interest in using a DSP. That will also throw out the buffer idea as well. As opposed to hijacking a thread, I thought it best to start a new one and keep it pure.

Why not a sigma-delta DAC. Frankly, because I can not control the digital filtering that occurs inside a sigma-delta DAC. Based on some of the waveforms out of these, I expect there is linear phase filters in at least some of them (Crystal). I would love to be proved wrong, but in the interest of purity, I would like to stay away from them initially.

Alvaius

[hifi]

I really think that design should have IV conversion and outputstage on the PCB but the possibility not to mount the components but instead another PCB with above to make any own design...

just my 2c...


btw wouldnt software for the Shark be a hassle?

what about cost??

/micke

[Peter Daniel]

Originally posted by alvaius
I did check that thread. Actually I have a few replies in it.

I was addressing hifi. I know you posted there. Sorry for confusion.

[jwb]

You didn't have to start this thread, because I was just warming up to the idea of using a DSP, but all's well.

Originally posted by alvaius

It seems there is a need for a "proper" OS DAC to be implemented and tried out. By "proper", I mean one where we have complete control over the digital and analog domain, i.e. we know exactly what is going on at all times, what filters are being used, etc.

I am not sure what you expect to accomplish by implementing your own FIR filter. In what way do you expect it to be better than manufacturers' FIR filters? Usually improvements in FIR filters involve making it go faster, not better.

To that end, I am proposing development of a DAC using the ADSP-21161 DSP and the PCM1704 DAC. Why these parts? The 21161 DSP can be used as a 32 bit or floating point DSP, it has rich audio ports, it is cheap, and relatively powerful. The PCM1704 is chosen because it can handle a 32x oversampled 44.1KHz audio stream. I would even consider the PCM1702 as it can do 64x.

The 1704 can do 768kHz, so only 16x (ok 17x) oversampling of 44.1kHz signals.

At this point, I am not sure whether we should implement minimum phase FIR filters for oversampling, or use IIR filters with higher order hold approximations. Even with the 21161, we may be limited in the number of FIR TAPS we can have at 32x or 64x oversampling. This will not be an issue with IIR filters. For IIR, we will stick to Bessel implementations to avoid ringing. Perhaps, a combination of IIR and FIR is in order?

Let's say we want 64 taps at 16x oversampling of 44.1kHz data. We need 64 coefficients (2KB RAM), 16 polyphase filters, 4 coefficients per filter. So each iteration required 4 multiply-accumulates, or 3 million MACs per second. The 21161 at 100MHz can sustain 400 million MACs/sec, so you may just barely be able to squeeze it in.

I would like to investigate adding a RAM buffer to completely eliminate PLL clock issues. We could run the output slightly slower than the input (trust me, you would never know). This would lower jitter to the limits of our clock source.

That would violate the principles of accounting. If the output is slower than the input, samples will be accumulating in the system, and that is impossible. The output rate must match the input rate. The best way to reduce jitter here is simply to use a low jitter receiver like the DIR1703 or an ASRC like the AD1896.

[alvaius]

The 21161 could be used for only a single channel. One of the reasons I am considering digital IIR is less processing requirements.

You can run the output slower, and yes you will accumulate samples, but heh, eventually the song has to end and you can play everything back! RAM is cheap and for this purpose it does not need to be fast. Why do this, to seek perfection, or a reasonably fascimile. As opposed to "screwing" with making PLLs behave perfectly, I would rather just not deal with the issue.

The other thing I was looking at was using an MCF5249 with an IDE interface and a CD-ROM and just reading out at higher speeds than audio requires and playing back at audio rates. Those cheapy CD-players with 10 second or more anti-skip do exactly this, but of course just without a CD-ROM.

Believe you are right about the 1704.

I came up with less than 300 mmacs/sec, more like 90. Need to look more into this.

No, the software does not worry me at all, most of it can be garnered from app-notes.

Why not rely on MFRs filters? One, they are all FIR. Two, I want a minimum phase filter, not a linear phase with associated pre/post ringing. I am not aiming for mathematical perfection, but hopefully audio perfection, something that sounds good coming out of speakers, not as the result of minimizing an error function, at least not at the output of my DAC. If I could minimize the error at the output of my speakers then I would have my goal.

[hifiZen]

Alvaius,

I have already designed 90% of the hardware for a ADSP-21065L based audio DSP board. I have not worked on completing the project for over a year now, because I have been sidetracked with other priorities, but, with the proper motivation, I may be persuaded to pick up the project again (actually, I plan to get back to it ASAP anyway...).

A few points:

I considered the 21161N, as it is about 3 times more powerful than the 21065L, but it is only available in <b>BGA</b> package!!! (yuk)

The 21161N should have waaaaay more processing power than you'll need for an OS filter. I initially planned a 6-channel system to go on the 21065 which would implement FIR low-pass filters for some subwoofer action... cutoff was 60Hz... that's around 1500 taps!!! With some creative tricks, the 21065 can do the crossover at 48kHz sample rate.

Here's how I would do things: 8x oversampling is about all you'll need if you plan to remain at 24bit wordwidth (output, of course). Beyond that, I think it would be prudent to start reducing the word size. If you're going for massive oversampling rates like 64x or 128x, well then you're in sigma-delta territory, and an FPGA based implementation will be more useful... which brings me to my next point: the hardware configuration for my DSP board, which includes (gasp!) FPGAs!

Current configuration is something like this:

- 4 layer PCB
- Atmel ATmega128 uC to act as "host" processor
- The Atmel uC has ports set up for user interface I/O (buttons, pots, encoders, whatever), LCD/VFD display interface (parallel bus, could be configured for serial + additional GPIO), RS-232 for connecting to a PC (I've considered replacing this interface with a nifty USB chip I have handy), ISP (in system programming port), IR command receiver etc...
- ADSP-21065L DSP chip - relieved of most overhead duties by the host uC
- SDRAM memory footprints for optional memory to complement the 4Mb available internal to 21065, if desired
- configurable flash footprint - supports a wide variety of flash memories from different manufacturers, and in various sizes to accomodate available parts and other requirements of the builder.
- 4x AD1896 footprints available on-board... these simplify DSP programming and multi-source applications by allowing everything to operate on a single sample rate (say 96kHz), and locked to a local master clock (either on-board or separate)
- two Xilinx FPGAs - these handle glue logic, clock division and distribution, sample format processing for DSP-to-peripheral mismatches, and I/O MUXing tasks for a huge array of GPIO (essentially arranged as daughtercard connectors)
- main output port is a big I2S bus, which I'm thinking of equipping with LVDS transmitters per the LVDS discussion/thread which appeared here on DIYA recently.

The board is set up as a reconfigurable audio DSP processor, and does not include DACs or SPDIF recievers etc. It is meant to be <i>just</i> the DSP, and to have the flexibility to connect to whatever other audio hardware is desired. I limited the design in this manner for two reasons. (1) Initially, the board was designed as a full AD1892/21065/CS4390 system - basically a complete multi-channel audio processor/DAC solution. However, the DSP circuitry is very dense, and requires a minimum 4-layer board for satisfactory 1st-time-right results (I don't have the money to risk having the prototype fail to work properly). 4-layer fabbing is expensive, so minimizing PCB size is important. Also, the CS4390 DACs I chose in the initial design have since become obsolete. I suspect that the same thing will happen again if I choose a new DAC, so it's better to have the DACs on a separate board to begin with. (2) related to that last bit, I want this board to be flexible for whatever evolution of the application I or someone else comes up with. That means, for instance, if I want to build a board with the surplus PMD100 I ripped out of my old CD player, I'd like to be able to plug it in and interface it to this DSP without problems.

Anyway, the design has evolved extensively over the past four years, and remains a pipe dream for me. But, now that I'm working full-time on DVD player designs, I've seen the gamut of what works and what doesn't, and I have a much better idea of how to go about laying out the PCB than I would have when I started the project. I'm glad it never materialized, but now I think the design is very mature, and ready to get finished off and turned into a PCB layout for prototype manufacture.

The DSP is still the 21065, but if you feel you'd like to pay to have the BGA 21161 packages mounted, it wouldn't take too terribly much work to change to the design. I actually have a couple of each DSP in my personal inventory here at home. Now, getting the BGA to work on a 4-layer board... that's another story! The 21161 is in a very tiny package - I think 6 layers may be needed just to route the traces.

If you'd like to pursue this further with me, by all means, please drop me an email and we can discuss more details offline. Numerous others have emailed after I posted about it here through the past year, so I know there's interest. In fact enough people have emailed me about it, that I'm sure there are still a few I have yet to reply to...

Maybe I will start a separate thread for this, but at some point, I will be hosting a website dedicated to this project... I just need to get some other stuff out of the way first, but around Feb/March 2003 I should be ready to start in on it again in a serious way.

Cheers,