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
> 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
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:
> which now starts ecasound like this:
> chrt -f -p 80 ecasound <various_options>
> and sets LD_ASSUME_KERNEL
> 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
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
More information about the linux-audio-user