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.