On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz
<letz(a)grame.fr> wrote:
After all these discussions on JACK2, D-Bus and
Qjackctl issues,
here are
some general comments:
1) JACK2 *default* compilation mode defines the same starting
scheme at
JACK1 was doing. So (beside possible bugs) it is supposed to be
completely
"interchangeable" with JACK1. It can be controled with Qjackctl as
usual.
2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus
based
control application... (jack_control is a simple python example of
a control
application part of the package). Using JACK2 compiled in D-Bus with
Qjackctl is a "receipe for trouble", even if if can be done in
some simple
use cases. (The point is that in this case the client auto-start
feature
starts the "jackdbus" exe instead of "jackd" with all of the related
"settings" issues).
3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a
Qjackctl
bug, so has to be fixed at the right place.
I don't see right now any raisonable way to fix this mess, better
than
adding even more complexity in the design... (Nedko any idea?)
Otherwise I
guess the only way is to make this totally clear for packagers :
1) is the
standard way that maintains complete compatibility with legacy
applications
and control applications. 2) is the "new" way to be used with new
D-Bus
based control application (patchage ??)... So it would mean 2
separated
packages.
this sounds like a mess. there is a control API. i believe it was
agreed that the control API could be accessed directly (from C/C++
etc), or via other systems for which translators/layers were added
(e.g. DBus). i can see no reason why anyone would want to use choose
between a JACK server that can be controlled via either DBus or the
control API but not both. what is going on?
The point is that when compiled in D-Bus mode, libjack behaves
differently regarding the way it start the server: it does not use
the fork+exec mode anymore but call the D-Bus service to start the
server. This "simple" change is the source of all the problems we
then see.
Stephane