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 [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
