17 May
2009
17 May
'09
7:59 p.m.
On Sun, 17 May 2009 13:57:29 -0400, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
I can't tell about the c/c++ API since I'm not really using it. The issue
here is with the legacy way of doing things: controlling jack from the
command line and it's set of switches, playing with PIDs, redirecting some
output...
Legacy can't work well along control API.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
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?