On Fri, Jun 19, 2009 at 4:03 PM, Lennart Poettering<mzynq@email-addr-hidden> wrote:
> On Fri, 19.06.09 20:39, Chris Cannam (cannam@email-addr-hidden-day-breakfast.com) wrote:
>
>>
>> On Fri, Jun 19, 2009 at 7:13 PM, Lennart Poettering<mzynq@email-addr-hidden> wrote:
>> > Questions?
>>
>> 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.
Sorry if this is too many questions, i have read the Pulse code and
the LKML thread and was wondering:
I was under the impression that SCHED_RESET_ON_FORK was needed to
safely enable RT mode in Pulse because Pulse runs untrusted client
code. If that's not the case then why is it needed?
What does RealtimeKit set the RR interval to? IIRC the default is
100ms, seems like this could cause desktop interactivity issues. What
determines the upper bound on the amount of work Pulse's RT threads
can do?
Without mlock(), what happens when the SCHED_RR thread starts taking
page faults? AFAICT, it will be scheduled out, but as long as it has
time slice left, it will be immediately rescheduled.
Lee
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Jun 20 12:15:02 2009
This archive was generated by hypermail 2.1.8 : Sat Jun 20 2009 - 12:15:02 EEST