18 May
2009
18 May
'09
6:50 a.m.
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(a)rncbc.org