On Sun, 03 Oct 2004 01:14:46 -0400 Lee Revell <rlrevell(a)joe-job.com> wrote: Hmm, can someone explain in clear words what the jack startup sequence should look like? I'm sure staring at the code will be more effective if one knows what it's supposed to do :) flo

On Sun, 03 Oct 2004 12:55:18 +0300 Sampo Savolainen &lt;v2(a)iki.fi&gt; wrote: Hi, a simple test will show you that this is not true. This program will exit and disconnect from the jack graph after 10 seconds. I don't get any xruns with it even a 2*32 frames. Jack's disconnection logic might still be flawed [if paul says so]. but at least in this case it doesn't show: #include <jack/jack.h> #include <iostream> jack_client_t *client; jack_port_t *iport; jack_port_t *oport; int process(jack_nframes_t frames, void *arg) { // actually do something jack_default_audio_sample_t *ibuf; ibuf = (jack_default_audio_sample_t*)jack_port_get_buffer(iport, frames); jack_default_audio_sample_t *obuf; obuf = (jack_default_audio_sample_t*)jack_port_get_buffer(oport, frames); for (jack_nframes_t frame = 0; frame < frames; frame++) { obuf[frames] = ibuf[frame]; } return 0; } int main(int argc, char *argv[]) { std::cout << "client_new" << std::endl; client = jack_client_new("foo"); std::cout << "port_register." << std::endl; iport = jack_port_register(client, "foobar_in", JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsTerminal, 0); oport = jack_port_register(client, "foobar_out", JACK_DEFAULT_AUDIO_TYPE, JackPortIsTerminal|JackPortIsOutput, 0); std::cout << "set_process_callback" << std::endl; jack_set_process_callback(client, process, 0); std::cout << "activate" << std::endl; jack_activate(client); jack_port_tie(iport, oport); std::cout << "running" << std::endl; // while(1) {sleep(1);}; sleep(10); jack_deactivate(client); jack_client_close(client); }

On Sun, 2004-10-03 at 07:38, Florian Schmidt wrote: I seem to remember this having to do with reordering the graph of clients, so you should try it with a bunch of clients already connected and working, probably one client will not trigger the problem. -- Fernando

--- Sampo Savolainen &lt;v2(a)iki.fi&gt; wrote: Are the jackd internals reworked when going into and coming out of "freewheel" and so that's also the cause of xruns? Freewheel is used in Ardour for Session Export. It essentialy takes the session out of realtime mode so an action like Export can be performed faster than realtime. ron __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

On Mon, 4 Oct 2004 14:29:49 +0200 Florian Schmidt &lt;mista.tapas(a)gmx.net&gt; wrote: Hmm, it looks like jack is already doing this. See jack_run_one_cycle() in jackd/engine.c:2351. if (jack_try_lock_graph (engine)) { /* engine can't run. just throw away an entire cycle */ driver->null_cycle (driver, nframes); return 0; } maybe there are other places though which just lock and block as result.. flo

On Sun, 2004-10-03 at 01:25, Florian Schmidt wrote: Would it be possible to add a debugging feature that would trap any use of a sleeping function by any SCHED_FIFO process, similar to the way CONFIG_DEBUG_SPINLOCK_SLEEP works in the kernel? Lee

On Mon, 2004-10-04 at 17:25, Florian Schmidt wrote: I'd be happy to test it if there was something for me to look at. I'm seeing some very strange Jack xrun results: 1) With no clients hooked up oover time I still get xruns 2) When alsaplayer is playing CDs I seem to get xruns between tracks. Not always, but often. 3) Most bizarre, I seem to get more xruns when I run jack in multi-aterm than when I run it in xterm. Go figure... Cheers, Mark