Messages in this thread | | | Date | Tue, 23 Nov 2004 15:46:22 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2 |
| |
* Rui Nuno Capela <rncbc@rncbc.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |