Il giorno Mon, 02 Feb 2009 15:07:58 -0800
Fernando Lopez-Lezcano <nando(a)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
answer:
- 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
up?
- 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
[2]
http://sourceforge.net/mailarchive/message.php?msg_name=200902020056.29654.…
[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