psi42
04-14-2004, 11:39 PM
Well, here I am, with a nice shiny (well, maybe not so shiny) new CD burner with a max 52x write speed. Isn't that just great?
I was quickly up and burning data at full speed, and still doing other things at the same time, but burning audio was a different story. When trying to fry a nice audio cd, my system (powered by a 1.7ghz P4) would stagnate, making it virtually unusable for anything else while the horrendous process wound it's way around the disc. On top of that, burning at any speed faster than 16x would cause consistant buffer underruns for no apparently explicable reason.
A little (read: a lot) of googling/STFW'ing later, I ran into this (http://lists.debian.org/cdwrite/2003/cdwrite-200308/msg00028.html) after I finally hit the right combination of search terms in google.
Another post then turned up here (http://lists.berlios.de/pipermail/cdrecord-support/2002-October/000523.html), which quotes from an old cdrecord release message:
Also note that due to a kernel design bug, Linux does not
enable DMA for ATAPI drives if the sector size is != 2048 (as
with RAW sector size 2448). This results in a high system load
So what seems to be turning up is that the kernel, at least when those messages were written, would only use DMA when writing in blocks of multiples 512 bytes. Since audio is not written in such size blocks, DMA is not used, thus accounting for the buffer underruns and system drag. Data is burned in multiples of 512 bytes, so burning data did not cause problems.
Next up are the
cdrecord alpha 25 release notes (ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01a25), which state:
- Try to support the half hearted and badly designed /dev/hd* interface
from Linux-2.6 in a more usable way.
The only reason for adding this kind of support is that the Linux kernel
hackers reject to fix the known DMA bugs in the already existing SCSI
transport interfaces in the Linux kernel. Using /dev/hd* is unfortunately
the only way to get DMA with sector size being 2352, 2448 or similar.
The next little jewel to turn up was this (http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2644.html). From this, one can ascertain that a fix was put into the 2.5 branch of the kernel some time ago. And we all know what came of 2.5...
It's upgrade to 2.6 time. :D
For all this adventure, the fix was rather anticlimactic...
I posted this to save some people some time...I really hope it does.
Basically all you need to do is upgrade to 2.6. It's about time too. :) 2.6 rocks.
~psi42
I was quickly up and burning data at full speed, and still doing other things at the same time, but burning audio was a different story. When trying to fry a nice audio cd, my system (powered by a 1.7ghz P4) would stagnate, making it virtually unusable for anything else while the horrendous process wound it's way around the disc. On top of that, burning at any speed faster than 16x would cause consistant buffer underruns for no apparently explicable reason.
A little (read: a lot) of googling/STFW'ing later, I ran into this (http://lists.debian.org/cdwrite/2003/cdwrite-200308/msg00028.html) after I finally hit the right combination of search terms in google.
Another post then turned up here (http://lists.berlios.de/pipermail/cdrecord-support/2002-October/000523.html), which quotes from an old cdrecord release message:
Also note that due to a kernel design bug, Linux does not
enable DMA for ATAPI drives if the sector size is != 2048 (as
with RAW sector size 2448). This results in a high system load
So what seems to be turning up is that the kernel, at least when those messages were written, would only use DMA when writing in blocks of multiples 512 bytes. Since audio is not written in such size blocks, DMA is not used, thus accounting for the buffer underruns and system drag. Data is burned in multiples of 512 bytes, so burning data did not cause problems.
Next up are the
cdrecord alpha 25 release notes (ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01a25), which state:
- Try to support the half hearted and badly designed /dev/hd* interface
from Linux-2.6 in a more usable way.
The only reason for adding this kind of support is that the Linux kernel
hackers reject to fix the known DMA bugs in the already existing SCSI
transport interfaces in the Linux kernel. Using /dev/hd* is unfortunately
the only way to get DMA with sector size being 2352, 2448 or similar.
The next little jewel to turn up was this (http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2644.html). From this, one can ascertain that a fix was put into the 2.5 branch of the kernel some time ago. And we all know what came of 2.5...
It's upgrade to 2.6 time. :D
For all this adventure, the fix was rather anticlimactic...
I posted this to save some people some time...I really hope it does.
Basically all you need to do is upgrade to 2.6. It's about time too. :) 2.6 rocks.
~psi42