linuxaudio.org

On Fri, Jun 19, 2009 at 9:03 PM, Lennart Poettering wrote:

quoted text
> On Fri, 19.06.09 20:39, Chris Cannam (cannam@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

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev