18 May
2009
18 May
'09
2:31 p.m.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
That is a lie, and you know it.
negative
* Jack-dbus is not just exposing the C API.
It is *not* an optional way to access the
C API as the OSC server that Marc described
would be.
It is exposing the C APIs (control and jack.h one). Most of them
(transport dbus interface development is halted in early stage atm).
It is *alternative* way to access it. And optional because it is enabled
optionaly at configure time. Using both interfaces can get things nasty
and this is clearly described in the packager doc available on the trac
wiki.
From http://trac.jackaudio.org/wiki/JackDbusPackaging :
D-Bus JACK and Classic JACK mixture
- If D-Bus session bus gets misconfigured/non-functional, user will get classic
auto-launching associated with:
- User is blind about what happens with JACK server execution, unless server is
manually started.
- No JACK D-Bus aware control/monitor applications can be used. They
will claim JACK server is not started (cannot be contacted) even
when JACK server is actually running and normal JACK applications
are connected and probably using it.
* It interferes with the C API.
Yes, with both C APIs (control and jack.h one)
* It forces itself between the client and the
server, even if the client does not want to
use dbus at all, and it breaks the C API.
client wants to use jack server and in jackdbus setup this is the way to
start it. The one who enabled jackdbus in this system forced jack
clients to use dbus for staring the server through the same jack.h API
as implemented in libjack.so (it is implemennted in libjackserver.so
too).
Otherwise tell me why running a client that
does not make a single dbus call is starting
a dbus daemon. Which then goes on to prevent
qjackctl, not using dbus, starting the server
it wants to start.
Because libjack.so implementation is using dbus to start the server (if
and only if dbus operation was enabled at configure stage).
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>