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