"Rui Nuno Capela" <rncbc(a)rncbc.org> 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>