On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote: > 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, -- FA Io lo dico sempre: l'Italia รจ troppo stretta e lunga. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev