Fons Adriaensen writes:
> That is a lie, and you know it.
> * Jack-dbus is not just exposing the C API.
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
D-Bus JACK and Classic JACK mixture
- If D-Bus session bus gets misconfigured/non-functional, user will get cl=
assic auto-launching associated with:
- User is blind about what happens with JACK server execution, unless se=
rver 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.=20=20
> * It interferes with the C API.=20
Yes, with both C APIs (control and jack.h one)
> * It forces itself between the client and the
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
> Otherwise tell me why running a client that
Because libjack.so implementation is using dbus to start the server (if
and only if dbus operation was enabled at configure stage).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----