Lee,
Thank you for your clear explanation. This is a point i'd totally overlooked,
and leaving the "-n -20" flag in the command line was just
"so-mechanical" (i.e., a remnant of the time where i'd run jackd w/o the -R
flag, and where i'd notice slightly better perf ...) I've just redone a
couple of tests without the -n -20 option and with my 2.6.11-preempt kernel
this doesn't seem to change anything indeed (wooow, thanks god, there are no
serious bugs ;-)))
Now, looking back on this, I must admit i also got a bit muddled up over
"nice" vs "priority" issues when i recently started working with a
2.6.14-rt
kernel. I could read in a previous post on this list that -to sum up- one
should have jackd running at a priority "higher than all irq handlers besides
the soundcard irq" (where soundcard=ieee1394 controller in my case): as i
take it, running jackd with, e.g., -P -70, simply increases the RT scheduling
priority of jack then (irrespective of the nice value of the non-RT part of
jackd if i understand what you said). Am i right?
(btw, jackd -P anynegativenumber triggers an error with my 2.6.14-rt kernel, i
get a "cannot use real-time scheduling (FIFO at priority -70) etc."; probably
the subject for another thread though)
Regards,
Syd
Running [jackd]
at a low nice value could cause non real-time parts of JACK to interfere
with the audio engine.