[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Chris Cannam]

On Fri, Jun 19, 2009 at 9:03 PM, Lennart Poettering<mzynq at 0pointer.de> wrote:
> On Fri, 19.06.09 20:39, Chris Cannam (cannam at all-day-breakfast.com) 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