Re: [linux-audio-dev] Help on threads needed

in the SCHED_OTHER class, its not possible to override the "fair scheduling" characteristics of the kernel scheduler. you can certainly use nice to adjust the relative priorities of the threads (well, actually, sched_setparam()) and this will alter the way the threads are scheduled. but the scheduler takes elapsed cycles into account, and sooner or later may choose to run a thread will lower priority than another runnable thread just because the latter one has been hogging CPU cycles. there is no way around this theoretical possibility, because its an intentional design. its also why SCHED_RR and SCHED_FIFO exist, because these scheduling classes are not covered by that rule. if a SCHED_FIFO thread can run, and there are no SCHED_FIFO threads ready to run with higher priority, then that thread runs, regardless of whether it uses 99% or 1% of available CPU time. try "man sched_setscheduler" for a decent overview of this.

the audio thread should run at (at most) (sched_get_priority_max() - 1) to allow for any watchdog system to run. it may be wise to add a watchdog thread that runs at sched_get_priority_max() and wakes up every 5 seconds or so to check that progress is still being made. JACK includes such a thread, for example. this prevents endless loops in a SCHED_FIFO code from taking complete control of a single CPU system. it would be nice if there was a way to do this outside the application (i.e. a system wide check), but i don't see anyway to do this.

IMHO, the GUI thread should not run SCHED_FIFO - nothing is really served by this.