Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2

[Ingo Molnar]

* Rui Nuno Capela <rncbc@xxxxxxxxx> wrote:

> OK. I tried 14 instances of jack_test. I even modded Florian's
> original source code, to let each client instance have 4 ins and 4
> outs, and to make things a litle bit heavier, all 4 inputs are mixed
> into each of the 4 outputs.

i tried your new test-client, and i've got a generic question: should a
jack client be able to generate an xrun via, other than via overloading
jackd? E.g. i'm wondering about the following behavior: if start up
jackd in the usual way:

  jackd -R -P20 -dalsa -dhw:0 -r44100 -p64 -n2 -S -P

and then i start a single test-client (jack_test.cpp):

 # ./jack_test
 seconds to run: 60
 client_new: jack_test-4215
 port_register
 set_process_callback
 activate
 running

and then if i now Ctrl-Z the Jack client, i get an immediate xrun
message from jackd:

  **** alsa_pcm: xrun of at least 2.119 msecs

and when i 'fg' the client again then jackd sees a big delay:

  **** alsa_pcm: xrun of at least 742.064 msecs

corresponding the amount of time i waited between the Ctrl-Z and the 
'fg'.

since the client runs as SCHED_OTHER, doesnt this mean that simple
delays between SCHED_OTHER tasks could cause xruns in jackd too? A
SCHED_OTHER task can be delayed indefinitely at any stage. So shouldnt
the test-clients have RT priority as well, to guarantee xrun-less jackd?

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/