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

[Eric Dantan Rzewnicki]

Jack O'Quin wrote:
> Eric Dantan Rzewnicki <eric at zhevny.com> writes:
>>How do I set jackd's priority?
> Use the -P option.

Thanks Jack.

I'm still working with CONFIG_PREEMPT_RT for now.
Current audiobox set up:
http://zhevny.com/doc/audiobox_settup
Current kernel config:
http://zhevny.com/doc/config-2.6.11-rc1-rt-v0.7.35-01-audiobox-1

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?


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

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.

there are 5 jackd threads started. Only one has prio 90 as specified 
with -P. It and 2 others are SCHED_FIFO, but the 2 other are prio 99. 
How did they get that?
The remaining 2 threads are SCHED_OTHER with prio 0. Is this expected 
behavior?


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?

Let's see .... have I missed anything?
I get >50MB/s for all my drives in hdparm -t tests.

Any other low latency best_(guess)_practices I should be aware of?

Thanks guys,
Eric Rz.