Subject: Re: [linux-audio-dev] Realtime restrictions when running multipleaudio apps .. Was: Re: disksampler ...
From: David Olofson (david_AT_gardena.net)
Date: Wed Jul 19 2000 - 06:46:59 EEST
On Tue, 18 Jul 2000, Erik Steffl wrote:
> Stefan Westerfeld wrote:
> >
> > Hi!
> >
> > On Fri, Jul 14, 2000 at 10:45:56AM +0200, Benno Senoner wrote:
> > > It would be nice to hear comments from other list members
> > > (David Olofson , Paul , Stephan etc)
> >
> > Okay, I'll try to briefly summarize my thoughts about realtime soundserving
> > generally, and your proposal and aRts specifically.
> >
> > Generally, I think if linux is to be accepted as usable platform for audio,
> > we should get around the one-app-only restriction. Soundserving in the user
> > space is IMHO the way to go. This means, one app, the soundserver, gets
> > /dev/dsp, and all other apps do their sound output with the soundserver.
> >
> > The soundserver should be "lossless" in a way for every app you could write
> > without the soundserver, there is also an equivalent implementation using
> > the soundserver. This rules out proposals like "we do a soundserver that
> > supports only IPC streaming", as this approach effectively kills all low-
> > latency apps.
> >
> > Thus, a realtime soundserver must somehow allow in-process execution, so
> > that the realtime parts of apps can be gathered inside the soundserver.
>
> crash of an application that runs inside of soundserver would crash
> soundserver, which in turn causes the crashes of all sound applications.
> how do you get around that?
>
> you could prevent the application crash (but every application would
> have to be aware of crashing sound server) but I don't see any workable
> way to prevent the audio server to crash.
>
> isn't shared memory for data communication fast enough?
It isn't about avoiding communication overhead, but about keeping the
kernel from getting a chance to do "silly things" every time we
switch from one application to the next.
That is, if we could force an immediate context switch without
"yielding" to the kernel (ie do it without running the normal "exit
from kernel call" code), the only overhead would be that of the
context switch (switching VMTs and that kind of stuff, to handle
memory protection), and that might just work.
Not as fast running it all in the same threads, but it could be made
somewhat crash proof by connecting the necessary signals to code that
unloads the currently executing in-process client/plugin. The risk of
one plugin thrashing shared memory areas and thus causing other
plugins to freak out is not eliminated this way, though, so one could
argue that such a hack would be lots of work for only slightly better
stability.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 09:27:03 EEST