On Fri, Jun 19, 2009 at 9:03 PM, Lennart Poettering<[email protected]> wrote: > On Fri, 19.06.09 20:39, Chris Cannam ([email protected]) wrote: >> Is it safe to assume that the PulseAudio libraries will use this >> method to acquire real-time scheduling for the audio callback thread >> of any application that uses the PulseAudio callback API directly? > > Uh. I thought about that. Not sure if we really should do that > though. In many cases, the app's IO callback might not really be that > well suited for execution in RT. And then it might end up being killed > by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn > and we could just make all IO threads RT at prio 1 or so. I am a bit > afraid that such a thing might backfire and we fuck up the scheduling > for everyone else too.
That's a fair point. Given history, I expect the last thing we want is to create an impression that providing good audio services in a distribution must be seriously detrimental to anyone's server workload. For my part, I have applications that use JACK if available, falling back first to PulseAudio's callback API and then to ALSA via PortAudio, using effectively the same callback code in each case. I'd be happy to add another couple of lines to improve the scheduling of my callback thread when using Pulse in a "desktop" context. A bit more code is no problem; there's already quite a lot of logic there: arguably too much, but I don't want to lose PortAudio because it provides portability, I don't want to lose the direct Pulse layer since it works best of the three for me in most desktop situations, and I don't want to lose JACK because, well, it's JACK. But I probably would mind having to explicitly include and link against DBUS libraries. I appreciate that my code is already using DBUS somewhere under the covers, but another explicit build dependency for two lines of code doesn't seem ideal. So a way to do this through the PulseAudio API would be very welcome to me. Chris _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
