Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments

From: MarcO'Chapeau <marco@email-addr-hidden>
Date: Mon May 18 2009 - 00:59:32 EEST

On Sun, 17 May 2009 13:57:29 -0400, Paul Davis <paul@linuxaudiosystems.com>
wrote:
> On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz <letz@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?

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon May 18 04:15:02 2009

This archive was generated by hypermail 2.1.8 : Mon May 18 2009 - 04:15:02 EEST