Jack O'Quin wrote: > Eric Dantan Rzewnicki <eric@xxxxxxxxxx> writes: >>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. good. thanks for confirming. >>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. 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?
