*** 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
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
The other thread and Sigma-Delta DACs
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
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
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.
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.
The 1704 can do 768kHz, so only 16x (ok 17x) oversampling of 44.1kHz signals.
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.
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 said:
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.
The 1704 can do 768kHz, so only 16x (ok 17x) oversampling of 44.1kHz signals.
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.
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.
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.
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.
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,
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,
hmm... i haven't done a BOM on it, or any recent cost estimate. Original project budget was $1500 CAD, or roughly $1000 USD, but the design has evolved extensively since then...
PCBs are the largest single cost - somewhere in the range of 250-400 each, depending on size... less if I get more than 2 boards done, so with several people going in, this cost has the potential for substantial reduction.
Even with a very limited PCB quantity, I don't think the budget would come close to $1000 any more, mainly because the SPDIF receivers, DACs and analogue circuitry have all been removed.
I'll sit down later this week and work out some kind of ballpark estimate...
PCBs are the largest single cost - somewhere in the range of 250-400 each, depending on size... less if I get more than 2 boards done, so with several people going in, this cost has the potential for substantial reduction.
Even with a very limited PCB quantity, I don't think the budget would come close to $1000 any more, mainly because the SPDIF receivers, DACs and analogue circuitry have all been removed.
I'll sit down later this week and work out some kind of ballpark estimate...
The board is set up as a reconfigurable audio DSP processor, and does not include DAC
Is this really a "DIY DAC " project? I can think of maybe 3 or 4 people on the DYI who can even begin to understand what you are talking about. When I was finishing my EE, the guy next door to me was building his own airplane. He was an aerospace materials fabricator. He still did not try to build a steath fighter........ ( although he did use some carbon fibre composites now that I think about it) Absolutely no offence intended.
From the movie Contact
"Small moves, Ellie, small moves. "
Fred
Is this really a "DIY DAC " project? I can think of maybe 3 or 4 people on the DYI who can even begin to understand what you are talking about. When I was finishing my EE, the guy next door to me was building his own airplane. He was an aerospace materials fabricator. He still did not try to build a steath fighter........ ( although he did use some carbon fibre composites now that I think about it) Absolutely no offence intended.
From the movie Contact
"Small moves, Ellie, small moves. "
Fred
Re: The board is set up as a reconfigurable audio DSP processor, and does not include DAC
I agree with you Harry, oops, sorry, Fred.
This is way over my academic head......
Alvaius and HifiZen I have great admiration for you that you can plan and complete such a project.
But if we agree we need a linear phase digital filter I was hoping the industry can offer such a filter as a IC. I know now NPC and Burr/Brown (now Texas Instruments) offer a soft rolloff option on some of there filters but I consider that "half work"
In the light of these developments my NON-OS KWAK-DAC looks ridiculously simple.
Hi,Fred Dieckmann said:
I agree with you Harry, oops, sorry, Fred.
This is way over my academic head......
Alvaius and HifiZen I have great admiration for you that you can plan and complete such a project.
But if we agree we need a linear phase digital filter I was hoping the industry can offer such a filter as a IC. I know now NPC and Burr/Brown (now Texas Instruments) offer a soft rolloff option on some of there filters but I consider that "half work"
In the light of these developments my NON-OS KWAK-DAC looks ridiculously simple.
Re: The board is set up as a reconfigurable audio DSP processor, and does not include DAC
You know, some people screamed at me "we don't want overkill, we want simple things". If someone feels very strongly about something, go for it. Don't try to get other peoples approval. I, for instance will uppgrade my DAC project which will seem very simple if you compare my with this DSP one.
Personally I feel this project belongs to a research lab. Does this technology really improve 44.1 sound? But I curious about wether this project produces something or not.
Fred Dieckmann said:
You know, some people screamed at me "we don't want overkill, we want simple things". If someone feels very strongly about something, go for it. Don't try to get other peoples approval. I, for instance will uppgrade my DAC project which will seem very simple if you compare my with this DSP one.
Personally I feel this project belongs to a research lab. Does this technology really improve 44.1 sound? But I curious about wether this project produces something or not.
I love it.
Im currently studying DSPs at TAFE as part of my EE diploma.
While i consider myself to be above the average in knowlege in my DSP class, im still having problems understanding what you guys are talking about.
But the great thing is, now that ive heard about this stuff, i can go learn about it myself which is great, as i think it is the best way to learn.
Anyway...
If you guys think you can do this, then why not build it?
It doesnt matter that the rest of us are scratching our heads trying to work out what your doing.... its still DIY.
Im currently studying DSPs at TAFE as part of my EE diploma.
While i consider myself to be above the average in knowlege in my DSP class, im still having problems understanding what you guys are talking about.
But the great thing is, now that ive heard about this stuff, i can go learn about it myself which is great, as i think it is the best way to learn.
Anyway...
If you guys think you can do this, then why not build it?
It doesnt matter that the rest of us are scratching our heads trying to work out what your doing.... its still DIY.
Fred, this is a fairly advanced project for DIY, but I think you underestimate the number of real hackers out there. I, for one, get hot just reading this thread
Too bad about those two FPGAs hifiZen. That will add a lot of complexity, and I'm guessing the design tools will be available for Windows only. Perhaps it will be possible to distill the design down to exclude the FPGAs by cutting some flexibility. Or perhaps some software could be moved from the FPGA to the DSP.
Anyway I of course love the idea of I2S over LVDS.
Perhaps you can shoot out whatever preliminary sketches, drawings, schematics, layouts, notes, and so forth you already developed, if you think we can hack it.
Regards,
Jeffrey
Too bad about those two FPGAs hifiZen. That will add a lot of complexity, and I'm guessing the design tools will be available for Windows only. Perhaps it will be possible to distill the design down to exclude the FPGAs by cutting some flexibility. Or perhaps some software could be moved from the FPGA to the DSP.
Anyway I of course love the idea of I2S over LVDS.
Perhaps you can shoot out whatever preliminary sketches, drawings, schematics, layouts, notes, and so forth you already developed, if you think we can hack it.
Regards,
Jeffrey
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.