Subject: Re: [linux-audio-dev] an open letter to Linus re: low latency
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Jun 24 2000 - 19:47:07 EEST
On Thu, 22 Jun 2000, Stefan Westerfeld wrote:
> >
> > example: why is it that enlightenment has to develop its own sound
> > server? kinda strange part of window manager...
>
> I think you can't blame anyone who is working on open source software (like
> Linus does) for not being interested in your-favourite-feature. People are
> developing the things they are good in and they are interested in. Everything
> else (developing things you are not good in or not interested in) wouldn't
> exactly help the software quality. ;)
>
> So the *most important* thing which is required to have sound mixing support
> or low latency or whatever in the kernel is somebody who really cares about
> it, who likes working on it and who is good at it.
>
> I personally tend to think that having too much sound stuff in the kernel
> isn't a good idea either. We also do not run X11 in the kernel ;-). You have
> some restrictions when writing kernel code, which you don't have when you're
> able to solve the same thing in user land. Thats why I am working on aRts,
> which can do the sound server thing esd does, too, but does a whole lot more
> and may be just the solid multimedia foundation you ask for.
Sorry Stefan, but I NEVER said the kernel should contain fancy "multimedia"
support within the kernel space (perhaps in form of loadable modules etc,
just like NT does with their GFX drivers and WDM drivers).
I am for putting in userspace as much stuff as possible,
and see the kernel as a mere process scheduler and IO device / VM abstraction
API.
Your arts soundserver (and all other audio software too) will suck BADLY on
stanbdard linux, no matter how you implemented it.
That is a fact, and since you are judging by ear in your tests,
and not by latency-diagrams ( RDTSC timing with 20ns precision),
you can't affirm "I have SCSI disks and never had latency problems on my box"
(as in your interview on linuxmusicstation).
Sorry that is untrue.
I have tested the latencies on SCSI boxes , and although better than IDE,
we are still moving in the 30-60msec range which is 5-10TIMES worse than
Windows and Mac.
And you can't say "just avoid disk I/O while you are playing arts from a
MIDI-keyboard, and you will be fine".
EVERY pro-audio guy will laugh at this.
(not to mention it's impossible to avoid disk IO on linux, because of syslog
messages ecc.
Therefore if we want Linux accepted by the pros, then we need to consider
worst-case latencies and not the average ones.
>
> Whatever: if you (or somebody else) is unhappy with linux (or especially the
> kernel) being not strong enough in the multimedia section, then doing some-
> thing about it (and contributing real work, and working with the kernel
> people to get it integrated) is probably the most efficient thing to do.
The kernel is the engine, and a broken engine will not make us succeed.
(the best userspace sequencer/HDrecorder/FX processor/sound-server will not
deliver good timings when run on top of a broken process scheduler, with
worst-case latencies in the range of 70-150msec)
Look at the size of the lowlatency patch: 40KB vs a kernel source size of
50-60 MB or so.
This means that the modifications were really tiny in order to transform Linux
from a crappy 100ms worst-case latency OS, to a rocking 2ms latency OS.
(the 41KB contain mainly these (from Linus) hated few preemption points).
Perhaps Jun Sun of Montavista may give us some explanations about REAL
alternatives to pre-emption points.
(those that do not imply a fully
pre-emptable kernel, and do not add much complexity or require a radical
redesign of the core parts of Linux)
I am not an expert in that field , but common sense says me that if you cant
shorten the codepath, then pre-emption points are the best compromise,
since the added overhead is really tiny.
The drawback is that when a new kernel comes you have to check that
the codepaths did not increased in length.
But that could be tested using extensive stressing tools which isolate
the problem precisely (sort of latencytest but which benchmarks specific
syscalls for example)
some of the strategies are found here:
http://www.mvista.com/realtime/rtsched_wp.html
Jun, perhaps there are some other experts at your firm that could tell
us about alternative solutions ? ( of course only those which Linus would like
:-) )
cheers,
Benno.
This archive was generated by hypermail 2b28 : Sat Jun 24 2000 - 19:18:33 EEST