Subject: Re: [linux-audio-dev] Realtime restrictions when running multipleaudioapps .. Was: Re: disksampler ...
From: David Olofson (david_AT_gardena.net)
Date: Wed Jul 19 2000 - 07:15:40 EEST
On Tue, 18 Jul 2000, Erik Steffl wrote:
> > For realtime we simply have to live with this crash-problem.
> > At least we do not get a complete system lockup but only a simple
> > segfault.
>
> I don't think it's as simple as that. most of the programs today have
> some sound support, for example all gnome programs (as far as I can
> tell, I checked the games, pan (news reader) and other gnome programs)
> have sound support. so if the sound server crashes, all of these
> programs crash. for a desktop system (including music studio system)
> it's almost the same as system crash.
No, they will just have to deal with the audio I/O being dead until
the RT daemon is up running again. The API emulation could deal with
this so that applications will never see any weird error codes or
anything; just a drop-out, or some zero input or dropped output data.
> I already had somewhat related problem, when i had no sound support,
> most programs ran, but as soon as I started alsa without oss support
> conmfigured, all gnome programs stopped working (well, I can still use
> --disable-sound to make them work). I mean these things affect the whole
> system, even though they are in user space.
Sure, ANYTHING you break will cause some programs not to work,
especially if the applications are stupid enough as to exit as a
result of not being able to acces some less important things, like
unnecessary (and often unwanted) sound FX.
> we (=it's quite often in linux community) criticize MS for putting
> everything in kernel just for runtime performance (think video drivers
> etc.) and now we're talking about doing exactly the same thing in linux.
No. This is a *user space* service, and not even one that has a valid
reason to kill programs using it as a result of an internal problem.
Only the RT plugins go down with the RT daemon, so the applications
are still in charge, in case they care to handle the situation
properly.
> the sound server segfault is not simple segfault, as long as all the
> apps are using it. and from the discussion it looks like they would have
> to since the sound server would have exclusive access to audio devices
> in/dev.
No. Just as esd can override /dev/dsp access, so can we. We can even
make the API emulation hide RT daemon crashes, as it will be running
either in the user process (like the library hook that overrides
open()/close() or whatever you need when running OSS applications),
or in a separate daemon.
With some dirty kernel hacks in the drivers (perhaps not needed with
ALSA...), you could even hook in a separate "fake" RT daemon that just
sleeps, waiting for the driver to say "Hey, I think the RT daemon
crashed or something!", making the fake daemon go "Ok, I'll take over
for a while, so that the apps not depending on RT plugins can keep
going as if nothing happened." The fake daemon could even run the
plugins that non-RT apps happen to depend on, due to being routed
through them.
How fool-proof do you want to get, considering that it's *soft* RT
applications we're talking about...?
> > David said you could add some memory protection to via a kernel module.
> > But that is too tricky IMHO.
>
> that might be a way to go... if it's possible.
Everything is possible (well, almost), but everything's got a price
as well... See my previous post for a possible way of doing it: In
short, a kernel call that does an explicit task switch, and then
bypasses the normal "exit from kernel" code when returning. Still
some overhead, and the hack might have to involve a change in the
main execution path of the kernel call code. (I think there are a few
other ways, though, like using another INT to do the new kernel
call, for example.)
Anyway, I doubt it's worth the effort, as it's only half a solution.
It's a whole lot harder than this to keep a misbehaving or crashing
plugin from disturbing other RT plugins, so the real demanding apps
will suffer anyway in most cases.
> >> But no one requires you to convert/run all your apps within this model.
> > Only the high-end ones will require so.
> > (I think Cubase + ReWire on windows does it in a similar way)
>
> as I understood the discussion the sound server would be for
> everybody. if only few apps would use it then you would not be able to
> run any other audio apps while you're running the sound server. that
> does not make much sense. the point of the sound server was to be able
> to use more then one app to access the audio.
Exactly. More than one app should be able to do *real time* work at
the same time, which is made possible through the remote controlled
plugin thing.
More than one application should be able to do soft RT work at the
same time as well. This can be handled by hooking up esd, oRts,... to
our RT daemon via streaming and/or plugins, or by hacking API
emulation libs (ALSA, OSS,...) that interface to the streaming API of
the RT daemon. RT daemon crashes can be hidden in the API emulation
libs; simple hack: sleep until the RT daemon is back.
//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:23:34 EEST