Le 17 mai 09 à 19:57, Paul Davis a écrit : > 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?
The point is that when compiled in D-Bus mode, libjack behaves differently regarding the way it start the server: it does not use the fork+exec mode anymore but call the D-Bus service to start the server. This "simple" change is the source of all the problems we then see. Stephane _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
