I'm using Linux because of the abundance of code, free tools and support community.apolon34 said:
I need to read digital audio from IDE using cdparanoia methods, and spit it out a serial port. I could spend tons of time rewriting code that already exists - IDE drivers, cdparanoia, etc... using VisualDSP++. When I'm done, I'll have a solution that requires less flash and SDRAM. But then, anyone who wanted to make changes or enhancements would have to buy VisualDSP++, which costs thousands.
Or I could just toss together a minimal Linux which already comes with an IDE protocol stack, audio interfaces and everything already in place. I'll write low level IDE and SPORT (for I2S) drivers. Then I just need to install a modified cdparanoia and some wrapper code that handles RS232 and I'm done. If I want flac or mp3, I'll port flac/mpg123/MAD/whatever - or someone else can do that.
Hi,
you shouldn't forget that you have to generate 2.8xxMhz data on one port, with less possible jitter.
I don't know anything about the dsp you're planning to use, but in my opinion the best way to handle it is to use interrupt triggered by an external clock.
Linux isn't a realtimer os and you'll have a delay, the time spent in kernel interrupt routine, before you can put data on the external port.
i think this is an issue !
Don't misunderstand me, I really like Linux but I don't think it's usable there. Of course, you can take all the code for ide from the kernel, that's GPL.
you shouldn't forget that you have to generate 2.8xxMhz data on one port, with less possible jitter.
I don't know anything about the dsp you're planning to use, but in my opinion the best way to handle it is to use interrupt triggered by an external clock.
Linux isn't a realtimer os and you'll have a delay, the time spent in kernel interrupt routine, before you can put data on the external port.
i think this is an issue !
Don't misunderstand me, I really like Linux but I don't think it's usable there. Of course, you can take all the code for ide from the kernel, that's GPL.
The DSP provides buffered serial ports (SPORTs, as they're called) with background DMA transfers.
The DSP will automatically pull the next sample from memory and spit it out the serial port, with no intervention from the OS or any of the programs running on top of the OS. As long as the DMA buffer doesn't go empty, there will be no lost samples.
The behaviour of the OS or applications will have no influence on jitter.
And even if I wasn't running linux, I would still be running a similiar 'multitasking' sort of system with multiple threads managing audio output, IDE CDROM access, serial port control, etc... which has the same set of "problems".
The DSP will automatically pull the next sample from memory and spit it out the serial port, with no intervention from the OS or any of the programs running on top of the OS. As long as the DMA buffer doesn't go empty, there will be no lost samples.
The behaviour of the OS or applications will have no influence on jitter.
And even if I wasn't running linux, I would still be running a similiar 'multitasking' sort of system with multiple threads managing audio output, IDE CDROM access, serial port control, etc... which has the same set of "problems".
apolon34 said:
Hey all, Im new to this thread so I would like some clarification.
I have read the thread from the start, and I thaught the origional idea was to extract the audio data through the IDE interface instead of just using it to control the CDROM. My question is, why does it look like this project is turning into a small computer? You don't need a very powerful micro or dsp to extract the audio data as the audio stream is only 176kB/s.
The only problems I see with the idea are:
1) It is a fact that while reading from the CD (from a specific place) there is a positional error and so you cannot read and extract the same data from the same place twice. This is why you need software to be able to join data streams together IF the stream is broken. This seems to be overcome these days with some CDROMs having protection agains this and so it does not exist.
2) A micro can easily extract the 176kB/s of data into an external buffer, but you need to feed that data to a DAC at a constant rate. This may be too much for one micro as you guys are saying, but if you can get two chips, one feeding the DAC and the other filling the buffer?? Or a DAC with a buffer that you only need to fill periodically (like a MP3 decoder chip!).
I have been researching this sort of project for some time, and am now designing a CD player for my masters project for a HiFi company. It looks like I will be doing exactly this in my project.
Sorry if this is long, but if you guys can think about these things, it would be much appreciated. I have been looking at such a design for a while, but don't really think it needs to go to the extent of putting an OS on it.
Carl
I have read the thread from the start, and I thaught the origional idea was to extract the audio data through the IDE interface instead of just using it to control the CDROM. My question is, why does it look like this project is turning into a small computer? You don't need a very powerful micro or dsp to extract the audio data as the audio stream is only 176kB/s.
The only problems I see with the idea are:
1) It is a fact that while reading from the CD (from a specific place) there is a positional error and so you cannot read and extract the same data from the same place twice. This is why you need software to be able to join data streams together IF the stream is broken. This seems to be overcome these days with some CDROMs having protection agains this and so it does not exist.
2) A micro can easily extract the 176kB/s of data into an external buffer, but you need to feed that data to a DAC at a constant rate. This may be too much for one micro as you guys are saying, but if you can get two chips, one feeding the DAC and the other filling the buffer?? Or a DAC with a buffer that you only need to fill periodically (like a MP3 decoder chip!).
I have been researching this sort of project for some time, and am now designing a CD player for my masters project for a HiFi company. It looks like I will be doing exactly this in my project.
Sorry if this is long, but if you guys can think about these things, it would be much appreciated. I have been looking at such a design for a while, but don't really think it needs to go to the extent of putting an OS on it.
Carl
Apologies for the lack of updates - spending 60-80 hours/week doing DSP software at work doesn't leave me in much of a mood to do more DSP when I get home. 
apolon34 - The DSP i'm looking at is 400MHz, and it has dedicated hardware for handling I2S with background DMA transfers. I've had the same DSP chip handling serial interface clocks over 50MHz with no problems.
carlbenton - this looks like a computer, but it's a typical embedded DSP system. The DSP chip costs $15 from digikey in a single quantity, and it has I/O and processing capabilities far beyond what this project requires. Hacking together multiple microcontrollers and logic might work too, but it's tough to make it cost less. And it's running an OS because there's a lot of code already available (IDE drivers, cdparanoia, etc) and because it provides an excellent base for code development and debugging without requiring a several-thousand-$ DSP tool suite.
apolon34 - The DSP i'm looking at is 400MHz, and it has dedicated hardware for handling I2S with background DMA transfers. I've had the same DSP chip handling serial interface clocks over 50MHz with no problems.
carlbenton - this looks like a computer, but it's a typical embedded DSP system. The DSP chip costs $15 from digikey in a single quantity, and it has I/O and processing capabilities far beyond what this project requires. Hacking together multiple microcontrollers and logic might work too, but it's tough to make it cost less. And it's running an OS because there's a lot of code already available (IDE drivers, cdparanoia, etc) and because it provides an excellent base for code development and debugging without requiring a several-thousand-$ DSP tool suite.
You would rather be an unemployed, and unemployable, telecom engineer who has to try to build stuff on your own? Maybe since you are a DSP wiz, you won't get fired when you turn 50 like all the rest of us.
I'm stuck inside, too. Only difference is that I can go outside when I get sick of breathing soldering fumes. Which is about now!
Some guy needs to borrow your Johnson book.................
http://www.diyaudio.com/forums/showthread.php?postid=661029#post661029
Jocko
I'm stuck inside, too. Only difference is that I can go outside when I get sick of breathing soldering fumes. Which is about now!
Some guy needs to borrow your Johnson book.................
http://www.diyaudio.com/forums/showthread.php?postid=661029#post661029
Jocko
I'd rather be an employed EE that doesn't have to work 60-80 hours a week... I love my job so I don't mind the extra hours - it just means that my hobby projects (like the DSP board that this thread is about) gets very little attention. And thankfully I don't have a family that I need to spend time with... yet.
but on the other hand, I have a steak marinating in the fridge back at the house and I can't wait to get home, crack open a cold one and fire up the grill...
My johnson book will remain here on my desk, where it's most useful. I bought it used off amazon.com for ~60% of cover price - still expensive, but it's definitely a worthwhile investment.
but on the other hand, I have a steak marinating in the fridge back at the house and I can't wait to get home, crack open a cold one and fire up the grill...
My johnson book will remain here on my desk, where it's most useful. I bought it used off amazon.com for ~60% of cover price - still expensive, but it's definitely a worthwhile investment.
Jocko Homo said:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.