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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
