linuxaudio.org

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

quoted text
> > "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.296...

[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

_______________________________________________

Linux-audio-tuning mailing list

Linux-audio-tuning@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-tuning