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

PrevNext  Index
DateMon, 18 May 2009 11:17:44 +0300
From Nedko Arnaudov <[hidden] at arnaudov dot name>
ToLinux Audio Developers <[hidden] at lists dot linuxaudio dot org>, JACK Developers <[hidden] at jackaudio dot org>
In-Reply-ToPaul Davis Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Follow-UpRui Nuno Capela Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Paul Davis <[hidden]> writes:

> On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz <[hidden]> 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?
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

Using the "dbus ate my babies" matra is causing mess because other
people don't think so. Using dbus interface in qjackctl would fix lot of
this mess and this is the reason I asked Rui about that. Of course "dbus
ate my babies" ppl would see usage of jackdbus in qjackctl as a bad
thing.

Does qjackctl support headless and multiserver jack setups?
How headless setups work? When someone logins through ssh, does it
access jackd server that runs as same user?

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
PrevNext  Index

1242634715.30460_0.ltw:2,a <87bppqkeon.fsf at usbix dot spacelabs dot org>