hi leonardo,
> Next week I'll be in Pisa, Italy, for a workshop held by some of the
> SCHED_DEADLINE guys. I'm not a serious dev but I do research and I'll be
> glad to evaluate the benefit of SCHED_DEADLINE for audio and jack,
> compared to SCHED_FIFO.
that would be nice! the interface is much more robust than SCHED_FIFO
and it is rather similar to time-constraint threads as found on mach
threads. and it perfectly maps to rate-monotonic schedulers as found in
audio systems ...
however my initial tests were not very promising: my multicore audio
engine performed worse when using SCHED_DEADLINE for the helper threads
compared to SCHED_FIFO ...
cheers,
tim
>> since recent kernels provide SCHED_DEADLINE, i'm porting my code to make
>> use of it.
>>
>> * is there any plan to migrate jack1 and/or jack2 to use this scheduling
>> policy for the jack thread(s) of the application?
>>
>> * what is the recommended way to set the scheduling policy of the jack
>> thread with the current API? afaict, the JackThreadInitCallback is
>> called before JackClient::AcquireSelfRealTime in jack2. (i cannot use
>> jack1 due to the old bug that jack corrupts the stack while trying to
>> pre-fault it)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jun 20 00:15:03 2014
This archive was generated by hypermail 2.1.8 : Fri Jun 20 2014 - 00:15:03 EEST