Subject: Re: [linux-audio-dev] Audio-Quality-HOWTO updated , latency: small corrections
From: Benno Senoner (sbenno_AT_gardena.net)
Date: to loka 07 1999 - 20:23:31 EDT
On Thu, 07 Oct 1999, Paul Winkler wrote:
> The Audio-Quality-HOWTO has been updated. The new version is 0.0.8.
>
> There are a few new juicy tidbits of soundcard information, some more
> info on 60-cycle hum, and a notice about kernel patches for improved
> realtime performance.
>
> http://www.ulster.net/~abigoo/pw_linux/Audio-Quality-HOWTO.html
> --
looking good !
but IMHO the notes on latency reducing are not very correct:
"Don't run top or similar, which make extensive use of the /proc file system."
true: on regular kernels heavy /proc filesystem access causes up to 20-30ms
latencies.
on 2.2.10-lowlatency-N6, no latency problems
"In linux/include/asm/param.h change HZ up from the #DEFINE HZ 100 line (and then rebuild the kernel)...
This can reduce latency, but increases CPU overhead - more scheduling per
second... HZ is the "jiffies" value, the basic interval used by the scheduler.
It is 100 on Intel platforms, but... As it is at 1024 by default on Alpha
Linux then I suspect there is no serious probs setting it to that on a
modern-ish Intel box."
increasing HZ is almost useless, except you need a more finegrained usleep()
(down to 2ms), but it doesn't help to lower the latency peaks during heavy
disk I/O , /proc etc, since when this happens the kernel doesn't reschedule our
audio processes.
"In the kernel sources, change DEF_PRIORITY ... (it) is defined in linux/include/linux/sched.h and controls the default maximum timeslice.
It defaults to 20 which corresponds to 200ms. A value of 1 means 10ms
timeslices. Setting this value to 1 TOTALLY DESTROYS the functionality of
nice.... lowering it means that each process runs for less time before schedule
checks for the next runner. It means in general the time between successive
scheduled runs of your code is less, this in general being a good thing for
(pseudo-realtime) stuff."
very bad idea IMHO, and Linus would 100% agree on this,
again the cause is not priority (lowering timeslices doesn't help) or HZ
related, but the reason is that when Linux is in kernel mode, it runs in a sort
of cooperative multitasking, that means, if a kernel routine doesn't check the
need of rescheduling for too much time , then you will get latencies,
regardless of your workaround tricks.
Jim then adds a caveat: "To be honest I have not yet had the application that stresses the system enough for these to make a major impact.
Since I upgraded my venerable 486 last year to a K5-166, I have loadsa
headroom. I've altered the HZ (1000) stuff on my kernel, Seems fine, I'm
planning on making it permanent."
increasing HZ to 1000 drops the overall performance by a few % (not much on a
PII), but in some cases there is an advantage:
for example the SB AWE64 MIDI out FIFO doesn't have an IRQ, therefore you must
use busywaiting or high frequency polling, and in fact
with the default HZ=100 you get up to 10ms MIDI-out latency which is bad ,
(but consider this MIDI hardware is crap, as Jaroslav and Paul
Barton-Davis pointed out). Increasing HZ to 1000 you don't get the full MIDI
bandwidth but come close to 60-70% ( 2000bytes/sec vs 3125bytes/sec from the
MIDI port), plus the MIDI out latency will go down to about 2ms when setting
HZ=1000.
As Paul Barton-Davis discovered even on a HZ=100 box using decent MIDI
interfaces (for example audiopci or trident), you can get close to the HW
limits, 1.1ms on his trident.
Paul Winkler: please add the above notes to your HOWTO,
since people should not be fooled by some wrong (and useless) workarounds.
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST