4 Feb
2009
4 Feb
'09
4:42 a.m.
Il giorno Tue, 03 Feb 2009 10:11:20 -0800
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> ha scritto:
What I meant there was (if I got how it works right):
- jackd already manages audio thread priority, which get SCHED_FIFO
and therefore can preempt every other process/thread in the system
- all other processes are sheduled SCHED_OTHER with various nice levels
So, isn't it better to schedule SCHED_RR audio processes (say lmms,
hydrogen and zynaddsubfx) so a cronjob, xorg, daemons and such can't
possibly preempt audio processes?
I think such a situation (i.e. a cronjob preempting zynaddsubfx)
would not give you xruns, but it could lead to audio dropouts
(zynaddsubfx not having time to process audio), which is as bad as xruns
'cause you lose your sound.
Same goes for any other setup in which some apps aren't connected to
jack or properly designed.
Yep, I run 2.6.28.
Thank for your reply, I've made my mind clearer on some interesting
points now.
bye,
Nicola.
- what's
the difference between running some app realtime, say
"jackd -R", as opposed to "chrt -r" that same app?[3]
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
priority of that single thread?
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
numbers.
I pays to have jack applications that are properly designed. Then you
don't have to worry about scheduling and priorities (in a properly
configured system).
- given audio threads already are highest
priority, isn't it better
to also schedule SCHED_RR all audio processes (with lower priority
than jackd and other audio threads) so no other process can eat cpu
time up?
Audio threads should be the only ones that need realtime scheduling.
What do you mean by "all audio processes"? 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 imagine this scenario being very close to the machine not having
enough power to fulfill the requested tasks.
If a round robin across all audio threads gives xruns a fifo on jackd's
audio thread would leave other ones with no cpu time left, I guess.
- apart from
irq threads, is there any other big improvement a -rt
kernel gives over "vanilla"[4] ones?
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...
[...]
[4] I use "stock" debian kernels
reconfigured with forced
preemption (low-latency desktop) and 300Hz timer and get pretty
low latency (1.5ms) with no xruns at all even under heavy desktop
usage
Latest kernels are known to be pretty good without the rt patch. Is
this 2.6.28.*?