[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

dieeasy 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. 

	Hi all,

I tried lmms using alsa output with SCHED_RR[1] (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[2].

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?[3]
- 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"[4] 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
to learn.

Bye, Nicola.

[1] imho SCHED_RR is better than SCHED_FIFO
[3] 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.
[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

More information about the Linux-audio-tuning mailing list