18 May
2009
18 May
'09
12:21 p.m.
On Mon, May 18, 2009 10:15, Nedko Arnaudov wrote:
"Rui Nuno Capela" <rncbc(a)rncbc.org>
writes:
Nedko, that just doesn't seem to hold against what Fons has been reporting.
are you implying that the jackdbus stack is ignoring any explicit jackd
command line arguments and honoring what is in its own config file ???
imnsho, that's not plain wrong, that's terrorism! it does "ate all your
babies" alright >:(
nuff said?
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, May 18, 2009 09:17, Nedko Arnaudov
wrote:
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.
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 ;)