To just rip data from a cdrom and generate an i2s stream doesnt seem that hard at all. PIC's are useless though, their throughput is lousy and the instruction set is dreadful - an AVR gets 1 MIPS per MHz and they can run up to 20MHz which should be plenty for the job.
I did also think of a dual CPU design - you could have one CPU doing nothing but sitting there, accessing the memory (controlled and arbitrated by the second CPU), generating the I2S stream locked to some external MCLK. The second CPU would do the work of reading ATA and depositing the ripped data in memory. A ring buffering system could be used to ensure that the reading CPU is only using RAM not being used by the streamer.
Another thing I thought of was some method to make the result of the ATA command end up straight in the RAM. I think you could do this with some clever bus wiring trickery. Effectively, youd have a cheapo DMA arrangement.
I don't see why the focus on using PC DRAM in any form. You'd only need about 1MB, and getting that in SRAM is cheap and easy enough. Adding DRAM into the mix adds the hassle of generating refresh timing etc, and that pretty much means you're adding a CPLD/FPGA to do it.
I did also think of a dual CPU design - you could have one CPU doing nothing but sitting there, accessing the memory (controlled and arbitrated by the second CPU), generating the I2S stream locked to some external MCLK. The second CPU would do the work of reading ATA and depositing the ripped data in memory. A ring buffering system could be used to ensure that the reading CPU is only using RAM not being used by the streamer.
Another thing I thought of was some method to make the result of the ATA command end up straight in the RAM. I think you could do this with some clever bus wiring trickery. Effectively, youd have a cheapo DMA arrangement.
I don't see why the focus on using PC DRAM in any form. You'd only need about 1MB, and getting that in SRAM is cheap and easy enough. Adding DRAM into the mix adds the hassle of generating refresh timing etc, and that pretty much means you're adding a CPLD/FPGA to do it.
In fact, the project could be easily realized done using a small x86 mainboard with a low power CPU like the AMD Geode, Intel Atom or any of VIA's offerings. Linux would run without problems, we'd already have SATA and IDE support out of the box, etc.
There's one problem remaining : getting the I2S signal. If a small PCI or PCI Express 1X card with an FPGA or DSP could be made along with a linux driver that would work without problem.
In fact, some VIA boards have LVDS connections, there might be something possible to do with this.
There's one problem remaining : getting the I2S signal. If a small PCI or PCI Express 1X card with an FPGA or DSP could be made along with a linux driver that would work without problem.
In fact, some VIA boards have LVDS connections, there might be something possible to do with this.
There are more new SATA optical drives than IDE ones.
But easier to work with, everything to do DAE with CDs on Linux is readily available.
If you use a PC, then you have not built a CD player... what you might as well be building is a media centre and you might as well just rip all your CD's to WAV/some lossless format.
You should tell Toshiba they never built HD-DVD players but PCs.
SFF boards are made for embedded applications, not everyday computing.
SFF boards are made for embedded applications, not everyday computing.
- Status
- Not open for further replies.