lkml.org 
[lkml]   [2004]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:1.855 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site