linuxaudio.org

On Tue, 2009-02-03 at 16:04 +0100, dieeasy wrote:

quoted text
> 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

> > > "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]

Jack will give SCHED_FIFO to just the audio thread of the client

application (which is normally the only one that actually needs that). 
> - how can I identify the audio thread and change scheduling/nice

quoted text
>   priority of that single thread?

I don't think you can. You can see the threads and their pids

in /proc/PID/task/ but you don't know which is which. They are just

numbers. 
I pays to have jack applications that are properly designed. Then you

don't have to worry about scheduling and priorities (in a properly

configured system). 
> - given audio threads already are highest priority, isn't it better to

quoted text
>   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?

Audio threads should be the only ones that need realtime scheduling.

What do you mean by "all audio processes"?
> - apart from irq threads, is there any other big improvement a -rt

quoted text
>   kernel gives over "vanilla"[4] ones?

The time kernel system calls spend in a non-preemptible state are

supposed to be lower than in a stock kernel (but the gap has been

getting narrower). That means that a process that is ready to run and

has SCHED_FIFO has a better chance of being scheduled in time, in the

stock kernel there could be delays in scheduling that cause the process

to be scheduled too late... (and you get an xrun)
> - does enabling "preempt RCU" make a big difference?
I have no idea...
> Sorry if some questions are trivial or already got answered somewhere

quoted text
> 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

SCHED_RR will be preempted when it uses up its time slice. That prevents

lockups but it means you could get an xrun anyway. 
> [2]

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

I would assume that's how it works. 
You don't want the whole app to be SCHED_FIFO, that would mean that, for

example, screen updates would potentially starve the audio threads. 
> [4] I use "stock" debian kernels reconfigured with forced

quoted text
>     preemption (low-latency desktop) and 300Hz timer and get pretty low

>     latency (1.5ms) with no xruns at all even under heavy desktop usage

Latest kernels are known to be pretty good without the rt patch. Is this

2.6.28.*? 
-- Fernando
_______________________________________________

Linux-audio-tuning mailing list

Linux-audio-tuning@lists.linuxaudio.org

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