[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)
dieeasy.moo at gmail.com
Tue Feb 3 10:04:47 EST 2009
Il giorno Mon, 02 Feb 2009 15:07:58 -0800
Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU> ha scritto:
> > I use "lmms" every now and then. I have never been able to get
> > "lmms" to work well with jack so I use it with ALSA as the audio
> > driver. This works fine though I can not use jack application
> > simultaneously. So in this case do I have to explicitly give "lmms"
> > SCHED_FIFO and rtprio? How (using chrt?) ?
> If you want you could use chrt. I don't know if lmms is multithreaded,
> if so you would/should change into SCHED_FIFO the audio thread. Even
> then the application should be well designed, otherwise it could hang
> the whole machine.
I tried lmms using alsa output with SCHED_RR (chrt) and reniced I/O
(cfq, iorenice) and I found out cpu usage (the one reported by lmms)
dropped significantly. After rescheduling many tracks that used 100%
cpu and still clicked got to play nicely with little cpu usage. System
stability had no issues. LMMS is already threaded and threading support
is improving with 0.4.x versions.
Having made some experiments with realtime scheduling and after reading
your words I'll try asking some questions someone here could perhaps
- what's the difference between running some app realtime, say
"jackd -R", as opposed to "chrt -r" that same app?
- how can I identify the audio thread and change scheduling/nice
priority of that single thread?
- 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
- apart from irq threads, is there any other big improvement a -rt
kernel gives over "vanilla" ones?
- does enabling "preempt RCU" make a big difference?
Sorry if some questions are trivial or already got answered somewhere
else, I looked around and found nothing relevant concerning these
questions. I'm not a kernel expert and just digging my way trying
 imho SCHED_RR is better than SCHED_FIFO
 it seems to me that using chrt to reschedule a process just
reschedules one thread, while lanching the same app scheduled with
chrt -r in the first place gets all threads scheduled realtime.
 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
More information about the Linux-audio-tuning