16 Jan
2005
16 Jan
'05
7:38 p.m.
Jack O'Quin wrote:
Ah! ok
but, ecasound doesn't get SCHED_FIFO that way, no?
(ecasound running w/pid 3764)
eric@audiobox:~$ chrt -p 3764
pid 3764's current scheduling policy: SCHED_OTHER
pid 3764's current scheduling priority: 0
or does ecasound's jack thread run inside jackd and not show up in ps
output?
Eric Dantan Rzewnicki <eric(a)zhevny.com> writes:
good. thanks for confirming.
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.
Either is fine. It forces glibc to use the old-style kernel
interfaces for threading, so it to uses linuxthreads instead of NPTL.
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?
Yes. The other two realtime threads are
the JACK watchdog timer and
the Linuxthreads manager thread. 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
You should probably set LD_ASSUME_KERNEL consistently for
all clients,
but the `chrt' should not be necessary. JACK will set all the client
process thread priorities to 89 (one less than 90), IIRC. You don't
want to mess with the other ecasound threads. They'll just interfere.