Il giorno Mon, 02 Feb 2009 15:07:58 -0800
Fernando Lopez-Lezcano ha scritto:
> > I use "lmms" every now and then. I have never been able to get
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
Linux-audio-tuning mailing list