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

"Rui Nuno Capela" <[hidden]> writes:

> hi Nedko,
>
> On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote:
>>
>> 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.
>>
>
> main trouble, imo, is that jackdbus is currently not playing fair game
> with qjackctl wrt. jackd auto-start functionality.
>
> as noted in one my other post, qjackctl always issues jack_client_open()
> with *JackNoStartServer* option, which explicitly instructs on jack stack
> for *never* start jackd on its call. apparently, jackdbus lacks this call
> and starts jackd no matter what, giving us all the "ate my babies" mantra
> ;)
>
> so it seems like just a missing piece in the jackdbus implementation re.
> the jack api. it this stands true, i guess it should be easily fixed so
> that future jackdbus and legacy qjackctl can still live on together for
> many years to come ;)


libjack does not start jack server if JackNoStartServer is
specified. This behaviour is same for both jackd autolaunching and dbus
jack server starting through activation. Presense of the jackdbus
process *DOES NOT MEAN* that jack server is started. It looks like fair
game to me.

>> 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?
>>
>
> well, of course, being qjackctl a X client, you can run qjackctl on the
> headless machine and render the GUI on your local X server (ie. your
> headtop, desktop, laptop, whatever) via ssh -X and DISPLAY trickery. if
> you add that to disparate JACK_DEFAULT_SERVER environment settings, you
> can have control of multiple jackd servers, either local or even remote.

Of course instead of (or together with) DISPLAY trickery one can use
DBUS_SESSION_BUS_ADDRESS and achieve the same effect. I.e. jackdbus
operation in headless mode. Moreover, one can have non-X11 mode (without
ssh X11 forwarding). The bad news is that ssh has built in support for
X11 forwarding but has no support for dbus. Looks like feature request
for openssh :D

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

1242638164.3802_0.ltw:2,a <874ovikc0x.fsf at usbix dot spacelabs dot org>