On Mon, 2007-05-21 at 13:03 +0300, Nedko Arnaudov
wrote:
William Weston <weston(a)sysex.net> writes:
This one looks like you may have hit a case where
the engine
thread is waiting on the buffer ready condition to be broadcast from
the jack thread, which never comes because JACK requested a client
shutdown instead of running the process callback. Does this patch
help?
The patch does not help. I beleive the AFAIK the jack_shutdown_handler()
is called only when jackd is being shut down, not during jack client
shutdown. I added printf in the function and it does not show during
phasex shutdown. It appeared however when I tried to stop jackd while
phasex was running (and there were some other strange messagest too):
# phasex
JACK tmpdir identified as [/tmp]
cannot read server event (Success)
cannot complete execution of the processing graph (Resource temporarily unavailable)
zombified - calling shutdown handler
jack_shutdown_handler() called.
I get the same here every time if i ^O (load a patch) in phasex whilst
something else is running in jack (eg seq24 & a single whysynth). If i
do the ^O whilst seq24 is stopped, i can load the patch without
problems, and i can then do subsequent ^O's whilst seq24 is running.
Check out the patch I just sent out to fix the JACK shutdown issues,
which should take care of phasex shutting down in an unfriendly way
when this happens.
I'll be looking into the patch loading issue next. From what I can
tell, the first access of the File menu (either by hitting it
directly or accessing an item through a keyboard acceleration)
causes enough of a CPU hit to disrupt other threads. This is the
only menu that currently uses the GTK stock items and keyboard
accelerations. Any GTK hackers out there have any tricks for making
sure a GtkAccelGroup has fully initialized itself?
--ww