On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz <[email protected]> wrote: > After all these discussions on JACK2, D-Bus and Qjackctl issues, here are > some general comments: > > 1) JACK2 *default* compilation mode defines the same starting scheme at > JACK1 was doing. So (beside possible bugs) it is supposed to be completely > "interchangeable" with JACK1. It can be controled with Qjackctl as usual. > > 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based > control application... (jack_control is a simple python example of a control > application part of the package). Using JACK2 compiled in D-Bus with > Qjackctl is a "receipe for trouble", even if if can be done in some simple > use cases. (The point is that in this case the client auto-start feature > starts the "jackdbus" exe instead of "jackd" with all of the related > "settings" issues). > > 3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a Qjackctl > bug, so has to be fixed at the right place. > > I don't see right now any raisonable way to fix this mess, better than > adding even more complexity in the design... (Nedko any idea?) Otherwise I > guess the only way is to make this totally clear for packagers : 1) is the > standard way that maintains complete compatibility with legacy applications > and control applications. 2) is the "new" way to be used with new D-Bus > based control application (patchage ??)... So it would mean 2 separated > packages.
this sounds like a mess. there is a control API. i believe it was agreed that the control API could be accessed directly (from C/C++ etc), or via other systems for which translators/layers were added (e.g. DBus). i can see no reason why anyone would want to use choose between a JACK server that can be controlled via either DBus or the control API but not both. what is going on? _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
