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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
