Burning audio disc literally 30x the system load of data disc

[xiphmont@xiph.org (Monty)]

Hi folks,

I've found a peculiar behavior in the 2.4.x series (using recent Linux
SG 3.1.2x) that I have to fix one way or another.  I've tried 2.4.20
as shipped by Debian and my hand-built 2.4.21.

In short, I've put together an audio editing workstation to replace
the aging Snotfish. When burning *data* discs, everything is as
expected; I can burn four discs simultaneously at 52x at ~15% total
system load (each burner is on its own busmastering controller... just
in case).  The CD burner buffers have never dropped under 95%.

However, burning *audio* discs, a single audio burn maxes the machine
out at 16x.  Both Athlon 2800+s are near-pegged and the CDROM buffer
regularly empties (here, burn-free keeps saving things).  ps and top
both indicate all the load is in the kernel, and strace shows cdrecord
is using the SG ioctl interface.  I've not yet investigated further,
but I'm about to.  I'm tossing this out hoping someone has a
head-start on the problem.

I think we all agree, especially when demostrated that four 52x data
discs (true 52x at the rim, as reported by cdrecord) work fine, that
one reasonably should expect the same performance burning audio.  Or
at least better than this :-)

The problem can be demonstrated very easily;

cdrecord dev=0,0,0 speed=0 -pad -data -v -v -data randomverybigdata

...works swimmingly.  No load, no worries, full speed.


cdrecord dev=0,0,0 speed=0 -pad -data -v -v -audio randomverybigdata

...begins at full speed and progrssively drops back to 16x as the
cdrom buffer keeps emptying. The whole machine stutters and freezes a
few times a second.  Cdrecord shows the cdrom drive buffer filling all
at once, then counting down to zero... pausing... filling all at once,
counting down to near-zero, etc.  The cdrecord fifo stays at 100%
through all of this; behavior is the same with and without 'realtime'
scheduling.  MGM and top indicate the CPUs are pegged within the kernel.

Monty