[PlanetCCRMA] qjackctl start/stop hanging on restart.

[Rui Nuno Capela]

Hi everyone,

As the author of qjackctl, and believing that some of you are using it :),
I'll humbly ask you here for some feedback about a showstopping issue that
is annoying myself. There it goes:

It has been reported that in some systems qjackctl hangs pretty badly after
stopping and restarting the JACK audio daemon, without quitting the
application. That is, each qjackctl running instance may only start and
stop JACK only once. After that, one have to quit and run it back again.
This situation only happens in specific systems, although very
deterministically.

I've done some homework and found something notorious:

a) It only happens if qjackctl's client codepath is activated, that is, if
jack_activate gets called. Of course, removing the call will cripple
pretty seriously all client functionality to a no-op. So this isn't a
solution but just a hint. Perhaps the qjackctl client thread messes with
its parent one, which is also jackd's?

b) Curiously, while executing under valgrind, qjackctl doesn't expose this
behaviour, probably due to greater lag times. So, this seems like some
particular race condition or what?

c) Once, i've been trying using 'popen' instead of 'system' as for shell
execution interface and as a means to stdout capture. The result was that
with 'popen' things get frozen pretty sooner.

Based on my experiments, this situation do happen on SuSE 8.1 and Debian
Woody based systems. It's _not_ a kernel issue, as in all my latest tests
the very same one was effective (2.4.22 lowlat+preempt+caps). On Red Hat 9
(Planet CCRMA) and Mandrake 9.1 there's _no_ experience _nor_ record of
this ever happenning.

So, if any of you are experiencing this undesirable behaviour, or any
other you may find annoying, please report it to me/us or by logging on to
the project's page (http://www.sourceforge.net/projects/qjackctl).
Remember
to describe your system briefly, namely libc, gcc and qt versions.

All help will be appreciated, of course ;)

Thanks for your precious time,
-- 
rncbc aka Rui Nuno Capela
rncbc@rncbc.org