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

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 ;)


> 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.

cheers
-- 
rncbc aka Rui Nuno Capela
[hidden]

1242636668.1237_0.ltw:2,a <15107.213.58.131.130.1242636643.squirrel at www dot rncbc dot org>