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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
