[LAD] [Jack-Devel] more jack/qjackctl madness : some comments

[drew Roberts]

On Monday 18 May 2009 12:34:41 Fons Adriaensen wrote:
> 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.

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.
>
>
> Ciao,

all the best,

drew