some ramblings...
If someone is going to design sth like this, in my opinion there's no benefit of doing it unless:
a) a memory buffer is included to aid with jitter elimination and limited error readout
b) exact audio extraction software that makes use of higher reading speeds of cd-roms
c) means to upgrade such software in the future
d) given all the above are accomplished, a particularly good noise isolation scheme cause after all you don't want to design the perfect drive only to be able to hear it whizzing annoyingly when you try to listen to music (unless you don't mind putting it in another room which will give you other problems)
Well I don't know anything about how to do a),b) and c) and I suspect I wouldn't know how to do d) either but even if I did know how to do the first three my guess is it would still be very hard to do d) and not end up with a drive that weighs sth like 30kg and is carved out of granite or sth. (it would probably be easier to design such a heavy drive operating at 1x in the first place without all the fancy software and come out with a better drive in the end - still guessing here...)
Another idea I've toyed with in my mind is whether writing the data permanently on a HardDrive and playing off that would be worthwhile. With the high capacity hardrives we have today I could fit my entire CD collection in a couple of them.
What I don't know is:
a) would such a scheme be quieter than above
b) how is audio data (or any data) read (or should be read) off the hardrive and would that increase jitter ?
stelios
If someone is going to design sth like this, in my opinion there's no benefit of doing it unless:
a) a memory buffer is included to aid with jitter elimination and limited error readout
b) exact audio extraction software that makes use of higher reading speeds of cd-roms
c) means to upgrade such software in the future
d) given all the above are accomplished, a particularly good noise isolation scheme cause after all you don't want to design the perfect drive only to be able to hear it whizzing annoyingly when you try to listen to music (unless you don't mind putting it in another room which will give you other problems)
Well I don't know anything about how to do a),b) and c) and I suspect I wouldn't know how to do d) either but even if I did know how to do the first three my guess is it would still be very hard to do d) and not end up with a drive that weighs sth like 30kg and is carved out of granite or sth. (it would probably be easier to design such a heavy drive operating at 1x in the first place without all the fancy software and come out with a better drive in the end - still guessing here...)
Another idea I've toyed with in my mind is whether writing the data permanently on a HardDrive and playing off that would be worthwhile. With the high capacity hardrives we have today I could fit my entire CD collection in a couple of them.
What I don't know is:
a) would such a scheme be quieter than above
b) how is audio data (or any data) read (or should be read) off the hardrive and would that increase jitter ?
stelios
Re: some ramblings...
If 1x is found to be unworkable, I'd just go with the lowest speed that can achieve realtime playback.rfbrw said:
I could be wrong, but I dont think rfbrw believes jitter will be reduced via the memory buffer technique.stelios said:
I'm not sure if I understand this part?
That is easy to implement via bootloader or in-circuit programming ability of many microcontrollers.
Filling a memory buffer as quickly as possible per rfbrw's scheme will create some noise, but handling this noise will be left up to whoever builds the enclosure.
Well I like the slow speed idea because it will remain pretty quiet I hope, and I also believe the drive will just "naturally" read more accurately at a lower speed. So hopefully I wouldnt have to mess with error correction.
I've also been thinking about a HD based player. HDs can be essentially inaubible - see silentpcreview.com
Again I dont believe this has any impact on jitter
Jitter isn't an issue. The CDROM drive itself doesn't determine how fast the audio is read from the drive - simply put, the controller asks for audio data from the drive and the CDROM gives it to the controller. This could happen at 0.5, 1x, 0.9999x, or even 5x.
The nice thing about this is that an IDE-based CD player is easily slaved off an external clock from a DAC. Or a high quality oscillator (guaranteed to be better than the CDROM's) could be placed on the board.
I'm doubting that any AVR has the horsepower necessary. Basically here's what the circuit has to do:
- pull data from the CDROM at 44.1KHz = 176.4Kbytes/sec, not including control packets.
- manage a FIFO; audio from the CDROM comes in packets, and has to leave at a constant rate.
- Send data out in I2S format. This could be done by an internal synchronous serial port, or be done by writing parallel data to an external CPLD at an exact interval.
This is too much I/O for an AVR. Here's what you really need:
- At least 8-16Kbytes of available RAM for an audio FIFO. Possibly more, depending on how "nice" (low-latency) the CDROM drive is.
- CDROM reading: have an actual asynchronous bus interface. Manually setting chip select pins low and high just won't cut it. Being able to do DMA reads from the async bus would be a very good thing, but it's not absolutely necessary.
- I2S output: could be done with CPLD doing serialization. Alternatively you could use a CPLD as a 1-bit FIFO and have the CPLD do SPI to I2S conversion. But ideally, your chip would have built-in I2S hardware which supports autobuffering DMA.
It's possible to do this with a very fast microcontroller, but to me, this whole project cries DSP.
I've got development tools (compilers and emulation hardware) for Analog Devices Blackfin and SHARC DSPs, and I'm more than willing to help out with this project.
I've got a fondness for the SHARC 21065L - it has a host interface suitable for a CDROM interface, I2S serial ports, UART for computer control and flash upgrades, glueless SDRAM interface, a nice amount of GPIO... all that good stuff, and it's dirt cheap. I've used it a fair bit. There's probably better DSPs out there for this though... Using a 21065 with external SDRAM/flash might require a 4-layer board, but you might be able to get a 21061 to work on a 2-layer board. But anyway, I'm just rambling.
The nice thing about this is that an IDE-based CD player is easily slaved off an external clock from a DAC. Or a high quality oscillator (guaranteed to be better than the CDROM's) could be placed on the board.
I'm doubting that any AVR has the horsepower necessary. Basically here's what the circuit has to do:
- pull data from the CDROM at 44.1KHz = 176.4Kbytes/sec, not including control packets.
- manage a FIFO; audio from the CDROM comes in packets, and has to leave at a constant rate.
- Send data out in I2S format. This could be done by an internal synchronous serial port, or be done by writing parallel data to an external CPLD at an exact interval.
This is too much I/O for an AVR. Here's what you really need:
- At least 8-16Kbytes of available RAM for an audio FIFO. Possibly more, depending on how "nice" (low-latency) the CDROM drive is.
- CDROM reading: have an actual asynchronous bus interface. Manually setting chip select pins low and high just won't cut it. Being able to do DMA reads from the async bus would be a very good thing, but it's not absolutely necessary.
- I2S output: could be done with CPLD doing serialization. Alternatively you could use a CPLD as a 1-bit FIFO and have the CPLD do SPI to I2S conversion. But ideally, your chip would have built-in I2S hardware which supports autobuffering DMA.
It's possible to do this with a very fast microcontroller, but to me, this whole project cries DSP.
I've got development tools (compilers and emulation hardware) for Analog Devices Blackfin and SHARC DSPs, and I'm more than willing to help out with this project.
I've got a fondness for the SHARC 21065L - it has a host interface suitable for a CDROM interface, I2S serial ports, UART for computer control and flash upgrades, glueless SDRAM interface, a nice amount of GPIO... all that good stuff, and it's dirt cheap. I've used it a fair bit. There's probably better DSPs out there for this though... Using a 21065 with external SDRAM/flash might require a 4-layer board, but you might be able to get a 21061 to work on a 2-layer board. But anyway, I'm just rambling.
Re: Re: some ramblings...
I'm referring to programs such as EAC (Exact Audio Copy) which I think work on the principle of reading and re-reading the same track until they have virtually eliminated any reading errors. Reading errors cannot be corrected in the way a data CDRom error is corrected as the error correction algorithms/technology used in creating a data CDRom was not available at the time when audio CD was standardized. Thus audio CDs are stuck with inferior error correction technology.
I don't know how such a program can be "sure" of having extracted a correct copy - possibly reads enough times to have a statistically good chance of extracting a correct track. There's a couple of such pieces of software available as shareware. My point is to use some similar algorithm to read the data and write it into a FIFO buffer - ideally an SDRAM.
A fast and accurate CDRom drive would come in handy here - Plextor drives have some attractive proprietary technology that limits reading errors (sth to do with obtaining a sync signal I think).
indeed - I just don't know how hard that is to achieve. Maybe not as much as I first assumed.
Perhaps but it might not necessarily lead to optimum results. One hand is slow but accurate and quiet and the other is possibly inaccurate but can read many times in a given amount of time, and noisier. Now which one will read the correct data remains to be seen in practice (or in theory).
Well, not so much if a large data buffer is used but I don't know what constraints on said data buffer size reading from a HD would impose. Maybe someone knows more about HD data retrieval out there ?
I think there's already been a relevant thread somewhere.
No, but it sets the upper physical limit. I don't believe jitter is an issue when an appropriate buffer exists and CDrom clock is a slave to DAC clock but I think I've read testimonies in this forum expressing reservations about the jitter induced by SDRAM chips.
I too feel it really shouldn't matter as I feel jitter only matters at the DAC chip.
ditto
I would add an EAC type algorithm and a fast Plextor drive or other of similarly low read out errors to this list.
Well after all nothing's set in stone and actual implementation is once again what matters. Since perfection is not attainable it's a question of how many different ways there are of achieving more than 90% of what's "perfect". The other thing is whether a Potential performance of say 93.5% is audibly different to say 92.5%.
Ok I think I'm through rambling for good now.
stelios
ghetto said:
I'm referring to programs such as EAC (Exact Audio Copy) which I think work on the principle of reading and re-reading the same track until they have virtually eliminated any reading errors. Reading errors cannot be corrected in the way a data CDRom error is corrected as the error correction algorithms/technology used in creating a data CDRom was not available at the time when audio CD was standardized. Thus audio CDs are stuck with inferior error correction technology.
I don't know how such a program can be "sure" of having extracted a correct copy - possibly reads enough times to have a statistically good chance of extracting a correct track. There's a couple of such pieces of software available as shareware. My point is to use some similar algorithm to read the data and write it into a FIFO buffer - ideally an SDRAM.
A fast and accurate CDRom drive would come in handy here - Plextor drives have some attractive proprietary technology that limits reading errors (sth to do with obtaining a sync signal I think).
indeed - I just don't know how hard that is to achieve. Maybe not as much as I first assumed.
Perhaps but it might not necessarily lead to optimum results. One hand is slow but accurate and quiet and the other is possibly inaccurate but can read many times in a given amount of time, and noisier. Now which one will read the correct data remains to be seen in practice (or in theory).
Well, not so much if a large data buffer is used but I don't know what constraints on said data buffer size reading from a HD would impose. Maybe someone knows more about HD data retrieval out there ?
rfbrw said:
I think there's already been a relevant thread somewhere.
gmarsh said:
No, but it sets the upper physical limit. I don't believe jitter is an issue when an appropriate buffer exists and CDrom clock is a slave to DAC clock but I think I've read testimonies in this forum expressing reservations about the jitter induced by SDRAM chips.
I too feel it really shouldn't matter as I feel jitter only matters at the DAC chip.
ditto
I would add an EAC type algorithm and a fast Plextor drive or other of similarly low read out errors to this list.
Well after all nothing's set in stone and actual implementation is once again what matters. Since perfection is not attainable it's a question of how many different ways there are of achieving more than 90% of what's "perfect". The other thing is whether a Potential performance of say 93.5% is audibly different to say 92.5%.
Ok I think I'm through rambling for good now.
stelios
It's incomprehensible rant time again! 
I'm not sure if anyone is serious about going ahead with this project, but I've been anxious to get a new side project on the go and this one should be fun to do. I spent last night putting together a basic design for this system, and came up with the following "core"...
- Analog Devices ADSP-BF531 DSP, the LQFP176 version. It runs at 400MHz, has onboard I2S, a SDRAM controller, and it's $17 from Digikey in a single quantity. It even runs Linux!
- 16/32/64 meg PC133 SDRAM chip, probably from Micron. It will be soldered onto the board - sorry, no DIMM socket.
- SPI flash from ST or Atmel holding the DSP code. It will be an 8 pin DIP, easy to remove and reprogram if needed.
- 74xx logic acting as a 3.3V/5V IDE bridge. The CDROM will sit in the DSP's memory mapped space. It will operate in PIO mode, but the DSP will still read from it using DMA.
- ADM3202 or similar providing a RS232 interface.
- Powered off 5 volts; 3.3V from a LDO, 1.2 volts from a LM3671, TPS54310 or similar integrated switcher. The power connector will likely be a 4-pin floppy power connector, since presumably this thing will be mounted next to a CDROM.
- likely a 4 layer PCB. It will be small.
I've designed a similar board using a 535 Blackfin. But since I probably won't be designing this board for myself, this means I have to bring other people's opinions into this. Soo... I'll need a few questions answered:
(1) How should we get audio off the board?
The Blackfin's I2S output will be operating in slave mode. Feed it a bit clock (and optionally frame sync, or it can generate it itself) and it will spit out I2S.
Sooo... should the board only put out I2S? should it put out SPDIF? toslink? AES/EBU? should it internally generate its clock? (and if so, using what sort of oscillator circuit?) or if not, should it receive an external SPDIF clock? or AES/EBU? or what? or heck? why not put an actual analog DAC on the board?
Rather than debating all of that, I'm inclined to just put a RJ45 or 8/10-pin ribbon header on the board and say "make your own output board". This external board will be responsible for feeding the DSP board an audio bit clock, and the DSP will send I2S clock/frame sync/data signals back to the board. Signal levels will be LVDS.
This way people can design their own OS/Non-OS/sigma-delta/etc DACs, choosing a Kwak or Tent clock or whatever, and just rely on my board as a source of data. Or a simple board with a few chips which produces SPDIF. Who knows? And since the clock is coming from the output board, you can't blame me for jitter!
(2) How should the CDROM be controlled?
I don't particularly want to make the DSP board directly responsible for scanning buttons, listening to IR remotes, and writing to the complete variety of HD44780 LCDs that are out there in ten different languages. It's certainly possible, but once again I want to leave this up to an external board; it's far easier for someone to get their hands on MPLAB, AVR Studio, WinAVR, etc... than for someone to get their hands on a license for VisualDSP++.
This is easy enough to do with RS232 and a defined command set.
(3) Should IDE hard drives be supported? how about CDROMs with WAVs burned onto them, or DVDs with WAV files? how about FLAC? MP3? The scope of this project needs to be defined.
cdparanoia-style reading of CDROMs is priority #1. Adding iso9660/fat32 parsing and WAV/FLAC/etc is further down in the priority chain.
anyway, that's enough for now...
I'm not sure if anyone is serious about going ahead with this project, but I've been anxious to get a new side project on the go and this one should be fun to do. I spent last night putting together a basic design for this system, and came up with the following "core"...
- Analog Devices ADSP-BF531 DSP, the LQFP176 version. It runs at 400MHz, has onboard I2S, a SDRAM controller, and it's $17 from Digikey in a single quantity. It even runs Linux!
- 16/32/64 meg PC133 SDRAM chip, probably from Micron. It will be soldered onto the board - sorry, no DIMM socket.
- SPI flash from ST or Atmel holding the DSP code. It will be an 8 pin DIP, easy to remove and reprogram if needed.
- 74xx logic acting as a 3.3V/5V IDE bridge. The CDROM will sit in the DSP's memory mapped space. It will operate in PIO mode, but the DSP will still read from it using DMA.
- ADM3202 or similar providing a RS232 interface.
- Powered off 5 volts; 3.3V from a LDO, 1.2 volts from a LM3671, TPS54310 or similar integrated switcher. The power connector will likely be a 4-pin floppy power connector, since presumably this thing will be mounted next to a CDROM.
- likely a 4 layer PCB. It will be small.
I've designed a similar board using a 535 Blackfin. But since I probably won't be designing this board for myself, this means I have to bring other people's opinions into this. Soo... I'll need a few questions answered:
(1) How should we get audio off the board?
The Blackfin's I2S output will be operating in slave mode. Feed it a bit clock (and optionally frame sync, or it can generate it itself) and it will spit out I2S.
Sooo... should the board only put out I2S? should it put out SPDIF? toslink? AES/EBU? should it internally generate its clock? (and if so, using what sort of oscillator circuit?) or if not, should it receive an external SPDIF clock? or AES/EBU? or what? or heck? why not put an actual analog DAC on the board?
Rather than debating all of that, I'm inclined to just put a RJ45 or 8/10-pin ribbon header on the board and say "make your own output board". This external board will be responsible for feeding the DSP board an audio bit clock, and the DSP will send I2S clock/frame sync/data signals back to the board. Signal levels will be LVDS.
This way people can design their own OS/Non-OS/sigma-delta/etc DACs, choosing a Kwak or Tent clock or whatever, and just rely on my board as a source of data. Or a simple board with a few chips which produces SPDIF. Who knows? And since the clock is coming from the output board, you can't blame me for jitter!
(2) How should the CDROM be controlled?
I don't particularly want to make the DSP board directly responsible for scanning buttons, listening to IR remotes, and writing to the complete variety of HD44780 LCDs that are out there in ten different languages. It's certainly possible, but once again I want to leave this up to an external board; it's far easier for someone to get their hands on MPLAB, AVR Studio, WinAVR, etc... than for someone to get their hands on a license for VisualDSP++.
This is easy enough to do with RS232 and a defined command set.
(3) Should IDE hard drives be supported? how about CDROMs with WAVs burned onto them, or DVDs with WAV files? how about FLAC? MP3? The scope of this project needs to be defined.
cdparanoia-style reading of CDROMs is priority #1. Adding iso9660/fat32 parsing and WAV/FLAC/etc is further down in the priority chain.
anyway, that's enough for now...
gmarsh said:It's incomprehensible rant time again!
I'm not sure if anyone is serious about going ahead with this project, but I've been anxious to get a new side project on the go and this one should be fun to do. I spent last night putting together a basic design for this system, and came up with the following "core"...
-----------------------------------------------------------------------------------
This will be an excellent project. However, the discussions here are all tangled with many 'wish' features.
As I see it, what is needed is not cdrom control, eac type rip functions etc. All these will be offered by the computer.
What is needed is a pci card with I2S and spdif outputs exttracted directly from the bus, with no limits on the resolution ie supports up to 32/192 format. This way, the computer can be used for the highest quality audio in digital format and avoids the use of ultra cheap pc components and power supplies in conjunction with motherboards that are not designed to extract audio properly for hifi, but uses $3 AC97 codecs!.
There will still be the problem of motherboards and cpus chipsets not designed primarily for audio and places the audio pci stream with all sorts of other devices that cause noise and interruptions.
You are in the wrong place. You should be here.
http://www.diyaudio.com/forums/showthread.php?s=&threadid=32506
No news. The design is certainly possible, and i'll gladly design the hardware. I'm not much of a high-level programmer though, so I'd want someone else to take over much of that... or if I had a really good "howto" on how to directly extract audio from a CD drive by firing ATA commands directly at it, then I might be able to tackle it myself. I dunno.ghetto said:gmarsh - any news? Are you still serious about developing? I would love to help out with the main control section, but the cost of the development tools you are using makes this impossible I'm afraid
Basically, the DSP will have an IDE device mapped directly to its memory space via a CPLD. You can read/write directly to the drive's registers, and start DMA transfers between the drive and the DSP's memory space in order to pull out audio in blocks.
Simultaneously, the DSP will have a DMA transfer constantly running which pulls audio data out of the DSP's memory and tosses it out a serial port in I2S format.
And there'll be a thread or two which monitors the UART for commands.
A lot of the code could be written in generic C (as if you were writing it for linux or something) and then I could port it to the blackfin.
they're ISO (optionally with joliet) or sometimes UDF for DVDs. Either way it involves parsing FATs, which personally I don't find all that fun.rfbrw said:
The goal here is to build a better, "zero-introduced-jitter" CD player. If there's a set of ATAPI commands for reading DVD-Audio from a DVDA disc in a DVD drive, then maybe I'll work on that eventually. But for the first software revision, CDs only..
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.