18 Dec
2007
18 Dec
'07
5:45 p.m.
On Tue, 2007-12-18 at 18:24 +0200, Nedko Arnaudov wrote:
Krzysztof Foltman <wdev(a)foltman.com> writes:
It just does whatever jackdbus did when run as jackd --dbus.
If that means it's running as some separate launcher thing that isn't in
fact jackd, then that'll need fixing. It /appears/ to work as it should
anyway
I don't see why there is confusion or debate involved here to be honest.
This separate executable thing is just plain weird from the user
perspective. Making everything more complicated and requiring users to
take a day course in weird d-bus lingo to start jack isn't progress:
jack_control start
If that doesn't start jackd, it doesn't do what it should.
That aside, everything else about the d-bus stuff looks pretty good
-DR-
Nedko Arnaudov wrote:
From what i've understood of Dave's patch, it enables jackd executable
to start jackdbus thing (same executable). I.e. no separate launcher
executable. So having jackd behave in orthagonal way is not
confusing? Like, jackd
process is running, why my apps cannot connect?!?!?
In normal situations, this jackd process (the launcher) would be only
short-lived (less than a second). It might hang for some reason, because
of faulty driver or something else, but then it would be a rare
exception, not a rule. Plus, it's no worse than what would happen in
non-dbus jack (where jackd would be present in process list, but would
not respond).
If the "jackd in engine mode" (jackd started with --dbus) is running,
applications are able to connect, aren't they?