Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated , CD-ripping additions
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe loka 08 1999 - 07:31:30 EDT
On Fri, 08 Oct 1999, Paul Winkler wrote:
> Thanks very much Benno and David for the information. I am dependent
> entirely on contributed information, so it's important to have
> knowledgeable people point out such problems.
> I have added your comments to the HOWTO and uploaded it again. (Didn't
> change the version number, though...)
>
>
Yea, is important that the user gets the truth about system performance,
hw/sw limits etc., not like M$ where they make some claims, but can't provide
proofs or reliable tests.
Just an additional note to CD-ripping, that I would suggest to add in your
HOWTO:
cdda2wav (and probably cdparanoia too), set the scheduling policy
to SCHED_FIFO during rippping to minimize changes of corrupted CDDA
files on crappy CDROM drives (old IDE CDROM drives), due to disk activity etc.
Modern CDROM drives (like the Plextor SCSI series and others (most SCSI and
modern IDE ones) provide bit-accurate audio extraction and large buffers.
That means there is no need for overlapping block reading
(to keep the track in sync) and high process priority for the cd ripping
software.
Some time ago when I was experimenting with low-latency and system stressing,
I discovered CD ripping with my plextor CRDOM 32x SCSI causes frequent
audio dropouts, since it is able to rip CDDA up to 24x = 3MB/sec which causes
high disk writing output.
After running the cdda2wav as a regular user , so that it could not acquire
SCHED_FIFO privileges, running low-latency software (for example a realtime
FX processor) while ripping CDs at 24x speed worked perfectly.
Again I was able to get 2.1ms latency.
That means we would be able to run our DJ mixing software with RT effects etc,
while in background we rip CDs at maximum speed.
(and maybe even compressing them using an mp3 encoder).
Try to perform all this tasks simultaneously on windoze.
:-)
The drawback could be that if you have an old crappy IDE CDROM drive,
and run a low-latency SCHED_FIFO process which does a lot of CPU computations,
your ripped audio could contain some glitches (but the low-latency app would
still function perfectly) , but in this case it's not Linux's fault, since the
audio processing has priority over the ripping, and the faulty CDROM drive
doesn't provide accurate CDDA data.
Note on your DROPOUTS section: (should mention it too in your HOWTO)
killing sendmail , syslog etc *MAY* help ,
but the general rule to keep low dropouts is to
avoid disk activity on unpatched kernels since it's the main latency source.
Of course, in order to get latencies <50ms you have to run your app with
SCHED_FIFO policy (need to be root for this).
You can take some ideas from my low-latency HOWTO at linuxmusicstation
(thanks to John Littler for publishing it)
I even provided a little commandline app which allows you to set SCHED_FIFO
to arbitrary processes.
That means if you have an old binary-only app which doesn't set SCHED_FIFO,
you can use the cmdline tool to set the RT scheduling policy.
When the lowlatency patches will (hopefully !!) get into the mainstream kernel,
the only rules left will be:
- tune the IDE disks with hdparm (as described in my HOWTO), especially DMA=on,
- use SCHED_FIFO for the audio thread (and don't run higher priority SCHED_FIFO
apps, but you can run lower priority SCHED_FIFO processes and get no dropouts)
- avoid disk I/O in the audio playing tasks,
that means if you read from/write to your audio to disk,
you have to use a 2 threaded model:
SCHED_FIFO audio thread ,which exchanges data (via you preferred IPC mechanism,
shared mem, pipes etc) with the disk thread which runs at lower priority.
My tests showed that running the disk thread at normal priority (maybe with
nice -10) or running it SCHED_FIFO (at lower priority than the audio thread)
made not a big difference in terms of disk performance.
since the disk thread waits almost all the time on read()s and write()s.
regards,
Benno.
Benno Senoner
E-Mail: sbenno_AT_gardena.net
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST