Subject: [linux-audio-dev] Re: a new application underway ... timing issues in a client/server enviroment
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka 09 1999 - 13:34:52 EDT
On Sat, 09 Oct 1999, Benno Senoner wrote:
[...]
> Of course one could choose to run the audioserver in kernelspace
> to provide even better timing (actually there is little proof that we will
> really get better timing during high system load),
Exactly. With SCHED_FIFO and the low latency patch, the peak latency seems to
be about the same as in kernel space. True, you have less flexibility than in
kernel space, but with a module providing some useful services (like the ALSA
sequencer, or our Multimedia Communication Core or whatever it will be), that's
a non-issue.
> but I'm strongly against of this, since there will be many buggy plugins
> around, which could take our linux box down.
> (see DirectX on windoze).
Agree. (Wonder what effect the new DirectX filter architecture will have on
Windows' stability, BTW. Filters execute in kernel context... A new dimension
in crashability? ;-) Only RTLinux performance can justify running plug-ins in
the kernel, and that is if you really need it. (Protected memory for RTL would
change things a bit, though.)
> Are there any valid reasons to NOT adopt my proposed audio client/server
> model ?
> By using sharedmen / efficient IPC, we could even run many
> low-latency apps simultaneously with only little overhead.
Well, the minimum "direct" latency that applications can get will depend a
little on how many applications are running. And starting a new thread with
higher priority would increase the lowest reliable latency for the ones
currently running.
I'd suggest that the server provides an API that lets clients ask what the
minimum latency is for a given priority. The server could also notify
applications when things are about to change. This would require some thought,
and it still can't stop applications from being rude and ignoring the system.
But it's certainly a lot better than no *possibility* to cooperate at all.
> I think kernel space belongs mainly to PCM/Midi driver,
> and maybe some eventrouter which has to be well tested and crashproof.
A basic Multimedia Communication Service that connects audio and event ports,
and encapsulates the device drivers as "built-in" clients... You could hook up a
central engine (user space or RTLinux), but applicatins that prefer hosting
plug-ins locally don't have to care, and can run without the engine.
Sounds a bit like ALSA on steroids...
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST