On Tue, 2009-02-03 at 16:04 +0100, dieeasy wrote:
Jack will give SCHED_FIFO to just the audio thread of the client
application (which is normally the only one that actually needs that).
> - how can I identify the audio thread and change scheduling/nice
I don't think you can. You can see the threads and their pids
in /proc/PID/task/ but you don't know which is which. They are just
I pays to have jack applications that are properly designed. Then you
don't have to worry about scheduling and priorities (in a properly
> - given audio threads already are highest priority, isn't it better to
Audio threads should be the only ones that need realtime scheduling.
What do you mean by "all audio processes"?
> - apart from irq threads, is there any other big improvement a -rt
The time kernel system calls spend in a non-preemptible state are
supposed to be lower than in a stock kernel (but the gap has been
getting narrower). That means that a process that is ready to run and
has SCHED_FIFO has a better chance of being scheduled in time, in the
stock kernel there could be delays in scheduling that cause the process
to be scheduled too late... (and you get an xrun)
> - does enabling "preempt RCU" make a big difference?
I have no idea...
> Sorry if some questions are trivial or already got answered somewhere
SCHED_RR will be preempted when it uses up its time slice. That prevents
lockups but it means you could get an xrun anyway.
I would assume that's how it works.
You don't want the whole app to be SCHED_FIFO, that would mean that, for
example, screen updates would potentially starve the audio threads.
>  I use "stock" debian kernels reconfigured with forced
Latest kernels are known to be pretty good without the rt patch. Is this
Linux-audio-tuning mailing list