18 Dec
2007
18 Dec
'07
12:25 p.m.
Krzysztof Foltman <wdev(a)foltman.com> writes:
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? Or maybe you should describe your "jackd process
running, apps can't
connect" scenario in more detail, in case I got it wrong? Basically,
what turn of events results in jackd running but not responding to events?
jack controller dbus object is... controller, not server. it allows you
to mange jack server. This includes starting stopping jack server and
also configureing it.
Some terms explained:
* jack server is the what is seen by jack clients (audio/midi, through
libjack).
* jack controller is a dbus object that can start jack server
* jackd is the name of the executable starting jack server and parsing
commandline arguments to configure both engine and driver
* jackdbus is the name of the executable providing jack controller dbus
object. it can start jack server, amoung other things it can do.
Discalimer: this is how it works now, not how Dave made it work.
You can have jackdbus process running and server stopped. And this
happens when you have jack controller dbus object activated but server
not started.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>