18 May
2009
18 May
'09
3:58 p.m.
On Monday 18 May 2009 12:34:41 Fons Adriaensen wrote:
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis
wrote:
Fons, are you able to make a screencast movie of what is going on with your
system and post it?
After reading this last round, things are even less clear and such an effort
may help make things plain.
the issue that qjackctl could consider is not
jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever,
*** It already does not work anymore. ***
I have the impression that you are missing part
of the picture.
Jack-dbus is not just an (optional) server using
the C API and providing access to it via dbus.
I don not know what exactly is happening but it
interferes even if clients are just using the
C API. And it breaks it.
If it were just an optional interface that e.g.
an app such as qjackct could use to 'enhance the
user experience' that would be perfectly fine for
me. I would just not use it. It would also mean
that jackd and libjack stay just the same, they
don't have to know they are being controlled via
dbus.
But the current implementation imposes itself,
even if clients are just trying to use the C API.
And currently, maybe because of a bug, or by
design, it breaks the C API.
There is IMHO *no* reason why jack-dbus should
**intercept** C API calls, start its daemon,
and take control. As long as no client is
accessing jack via dbus, it should just not
be there. Those clients that want to use dbus
can apparently launch the server just by trying
to talk to it.
Ciao,
all the best,
drew