On Tue, 2007-12-18 at 18:24 +0200, Nedko Arnaudov wrote:
> Krzysztof Foltman <wdev@email-addr-hidden> writes:
>
> > Nedko Arnaudov wrote:
> >
> >> 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?
>
> 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.
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-
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Dec 19 00:15:49 2007
This archive was generated by hypermail 2.1.8 : Wed Dec 19 2007 - 00:15:49 EET