17 Jan
2005
17 Jan
'05
10:47 a.m.
Florian Schmidt wrote:
That explains why I saw 2 threads with prio 99, or at least one of them.
Do you know what the other would be?
joq explained this yesterday. I think you're right that the .x doesn't
matter much.
Ok. Sounds like my scratchiness problem is not necessarily kernel related.
thanks,
Eric Rz.
On Sun, 16 Jan 2005 17:15:13 -0500
Eric Dantan Rzewnicki <eric(a)zhevny.com> wrote:
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..
ok. thanks.
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.
I tried without first and noticed that jackd didn't start any threads.
The one it did have was SCHED_OTHER and prio 0. I have nptl 0.60, which
I gather is the problematic version.
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>
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
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.