Re: Underruns on Audio CD Burns
Joerg Schilling wrote:
Bill Davidsen <email@example.com> wrote:
I have an interesting problem burning one CD, I keep getting underruns.
I can avoid it by using a low speed burn, or live with it with the
burnfree option, but I don't understand why it occurs.
The system is a P4-2.8G, 1GB memory, 40x CD burner. The O/S is FC1,
latest 2.4.22 kernel, and the burner runs in ide-scsi. The burn was done
as root, no warning messages, nothing else running. After the first bad
burn I checked that DMA and interrupts were enabled on the hard disk,
and set the fifo size to 50MB, larger than the longest track (22MB).
cdrecord is 2.01a31 and I tried the 2.01a19 which comes with FC1.
If this is true, then you need to contact the Linux Kernel peopel for a fix.
BTW: you are using outdated software.
2.01a19 is 15 months old
As noted cdrecord in normal use is 2.01a31, I tried the distributed
version in case there was a Redhat-ism needed. The a31 AN file is date
June 2004, built from your source, unless there were major bugs, that's
not the issue, I was trying the obvious things and using the version
which came with the kernel before asking for ideas.
How about -pad, would there be any reason for that to cause slowdown?
The recording process from the original tapes may not be always the
right length, and my .inf file builder rounds up and warns to use -pad,
I can rerun with the truncate option so -pad is not needed. Or could the
-useinfo cause overhead?
What I don't understand is why/how there could be an underrun when the
fifo is larger than the track. It almost sounds as if the application
were not filling the fifo before starting the burn, but the minimum fill
was 95%, so that seems unlikely. I looked at the code quickly and saw no
obvious cause for this. I also watched the CPU usage which burning, and
it was always 60-70% idle. Since it ran at RR priority there should be
no issue with CPU performance.
It sounds like either the Kernel is not performant enough to send the
SCSI commands fast enough or that an unfriendly "other" application is
trying to break into the communication between cdrecord & the drive.
Example? I have disabled any automounting options long ago, is there
some other evil daemon which might be running?
Thanks for the feedback.
bill davidsen <firstname.lastname@example.org>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979