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

Rui Nuno Capela rncbc at rncbc.org
Mon May 18 08:50:43 UTC 2009

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.

rncbc aka Rui Nuno Capela
rncbc at rncbc.org

More information about the Linux-audio-dev mailing list