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
rncbc@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev