[linux-audio-user] realtime-preempt-2.6.11-rc1-V0.7.35-01

Florian Schmidt mista.tapas at gmx.net
Mon Jan 17 07:22:22 EST 2005

On Sun, 16 Jan 2005 17:15:13 -0500
Eric Dantan Rzewnicki <eric at zhevny.com> wrote:

> I set my IRQ handlers' priorities like this:
> p=99 ; for i in 1 9 11 8; do chrt -f -p $p $i; p=$(($p-1)); done
> where:
> IRQ 1   i8042 (keyboard)
> IRQ 9   ice1712 (delta66)
> IRQ 11  ymfpci (used only for midi
> IRQ 8   rtc (is setting prio for this necessary?)
> I set the prio for the rtc because the wiki says to turn off threads for 
>   it ... but, from what Florian said earlier that is only for 
> desktop-preempt now. Since this kernel is realtime-preempt and all 
> handlers are threaded, do I still need to treat the rtc specially?

The rtc prio only needs to be high when you use a software that needs
the rtc. I think, some midi sequencers use it (used it), so i thought it
doesn't hurt when i advise people to give it a high prio, too.. When
it's not used, the high prio shouldn't have any negative effect either..

> jackd starts fine like this:
> LD_ASSUME_KERNEL=2.4.22 jackd -v -R -P 90 -d alsa -d ice1712 -p 64 -n 2

90 is a bit high. jack also starts a watchdog thread with a prio +10.
I'd recommend a prio of 60 or 70 for jackd. May i ask why you use the
LD_ASSUME_KERNEL hack? Do you get bitten by the nptl-hell? Try running
jackd without it and check the threads with chrt.

> no xruns except the expected ones on client connect/disconnect. Does it 
> matter which version of 2.4 is assumed? I've seen .22 and .19 in various 
> places.

I don't think so. But i'm not sure. I think for libc the only important
thing is that it's a 2.4.x version and thus uses the linuxthreads
implementation instead of nptl..

> I can run this script:
> http://zhevny.com/bin/ecamynthes/ecanoscl-i-0.0.2.sh
> which now starts ecasound like this:
> chrt -f -p 80 ecasound <various_options>
> The script runs fine and connects to jack, but the audio it produces is 
> very scratchy. This may have something to do with ecasound itself, 
> though, since I upgraded that yesterday. Is it possible that the extra 
> CPU overhead of preempt_rt is causing this? I'm guessing not since my 
> box has >2GHz cpu, but maybe it isn't only about cpu power ...
> How significant is the extra overhead of preempt_rt compared to 
> preempt_desktop?

Has anyone done any statistics? Well, i run preempt_rt on a 1.2ghz
athlon here and it works fine for audio stuff. I don't see any obvious
performance differences.


Palimm Palimm!

More information about the linux-audio-user mailing list