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

Eric Dantan Rzewnicki eric at zhevny.com
Mon Jan 17 09:47:06 EST 2005


Florian Schmidt wrote:
> On Sun, 16 Jan 2005 17:15:13 -0500
> Eric Dantan Rzewnicki <eric at 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. 

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.



More information about the Linux-audio-user mailing list