Well, I think this is fundamentally a good idea.
I just thought someone ought to say that.
I quite understand the frustration Paul expresses about the existing
methods of doing this never having being fully exploited, but I can
see why this has happened. It's still simple enough to put your user
or group name into limits.conf and get "proper" scheduling if you care
enough; meanwhile, I think there's something reassuring about the
provision of a fallback way of getting "good enough for the rest of
us" scheduling without too much danger of rogue applications melting
the naive user's computer. Since I like to think of much of my
software as being of use by random persons who have a passing interest
in music and audio, I think this could be a very good thing.
I had a few questions and still have some concerns about the
implementation, but actually I'm even coming around to the idea of
dumping in a couple of DBUS calls into my application code rather than
using a library -- it has the advantage that I can do it right now (or
whenever I get around to it) without having to worry about distro or
library support, since nothing is lost if the service isn't available.
And since I probably only want it for the Pulse driver, that makes it
slightly less onerous to demand the extra dependency on DBUS, since I
know that any system with PulseAudio will have the DBUS libraries.
Altogether, though it doesn't feel like the most elegant solution to
the problem (shunting the whole problem off to the audio layer would
be preferable), it could work out quite nicely.
Chris
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 16:15:04 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 16:15:04 EEST