Florian Schmidt wrote: > On Sun, 16 Jan 2005 17:15:13 -0500 > Eric Dantan Rzewnicki <eric@xxxxxxxxxx> 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. That explains why I saw 2 threads with prio 99, or at least one of them. Do you know what the other would be? > 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.. joq explained this yesterday. I think you're right that the .x doesn't matter much. >>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. Ok. Sounds like my scratchiness problem is not necessarily kernel related. thanks, Eric Rz.
