artswrapper defanged

[Stefan Westerfeld]

   Hi!

On Tue, Jul 16, 2002 at 10:39:57AM +0100, Rik Hemsley wrote:
> > Second, for the reasoning of why artswrapper exists: you can not guarantee
> > dropout-free sound at low latencies with the standard linux timesharing
> > scheduler. Some applications however, such as quake or Brahms need low
> > latencies to be useful.
> 
> Quake does not need to be suid to provide sound quick enough. It works
> just fine without.

Quake uses memory mapping of /dev/dsp. This allows it to render some sound,
go back to an earlier place and render some new piece of sound. If you want
to run Quake with a sound server, it can not "cancel" data it has rendered,
as the data flow is modelled as a stream here. This is why you only want to
premix a small buffer on the sound server.

Small amounts of buffering cause dropouts unless you are priorized.

> How many people need artsd to provide them with 'realtime' sound ?
> It looks like it's only Brahms users.

It seems to me that its all games, and even trivial applications like mp3
players or playing konsole beeps (you don't want to have your beep a long
time after you typed it) benefit from lowish latency. Every place where you
have the user do something, and the system react by a changing sound constrains
the buffer size to a low level, which is only safe with realtime priority.

> How about we enable realtime scheduling only when someone is using
> an app which requires artsd to have such privileges ? Quite easy to
> do in a pretty way. kdesu can prompt the user and you can show a dialog
> warning about the possibilities for bad things happening.

Well, dynamically adapting latency on the sound server (currently, you
configure the latency on startup, and it remains that way until you finish
artsd) is hard to implement. You have to reopen the OSS device whenever you
change latency, and you have to have explicit APIs for doing this (i.e. like
requesting a certain latency, asking for the current latency, releasing the
latency you requested). But of course its a nice feature to have, but given
its complexity to introduce it into the current artsd, I think I will not
implement it. Its a lot of work, and the benefit is not *that* big.

> Note that even without a DoS from another local user, you can have your
> system hang due to a bug in artsd. Last time I installed artswrapper suid,
> the system hung solid when I started artsd.

It doesn't hang due to bugs. Try adding

    for(;;);

to an arbitary place. Artsd will catch that and kill itself after 15 seconds
due to its self-cpu-usage-monitoring. If it does not, this is a bug and should
be fixed. Let me know, then. But I haven't seen it happening on my machine
since the monitoring code was introduced.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-