On Tue, May 19, 2009 09:38, Stéphane Letz wrote: > Hi All, > > > After hours of discussion on #jack IRC, it seems that we are in a > completely blocked situation: > > 1) we currently have 2 "incarnations" of the jack server named "jackd" > and "jackdbus". "jackd" is the legacy "classic" version of the server that > interact with the ~/jackdrc setting file. This setting file may be written > by Qjackctl or Ardour. "jackdbus" is the new D-Bus aware version of the > server, it use a completely new setting management system using a > "conf.xml" file. Il may use a multi-setting system in > the future. > > 2) the *heart" of the problem Fons initially told about is in the way > applications "auto-start" the server. This launching strategy is part of > libjack and depends of the incarnation of the server (jackd of jackdbus) > that is supposed to be used. Right now this strategy is chosen at *compile > time*, so that in "classic" mode the "jackd" server will be launched using > a fork-exec strategy, or in D-Bus mode the "jackdbus" server will be > launched by issuing a D-Bus call. > > 3) Since the "auto-start" strategy is chosen at compile time and thus > is coded in libjack, users will typically encounter all sort of problems as > soon as the used applications interact with a "D-Bus based strategy" > libjack (that will launch "jackdbus" incarnation) and users still use > Qjackctl that interact with the "jackd" incarnation. > > > 4) Different ideas have been proposed to merge the 2 "jackd" and > "jackdbus" incarnations in a unique extended "jackd" exe, but nothing > really clear emerged. > > 4) A possible proposed solution was to define 2 completely separated > packages for jack2 : the "classic" one would package the "jackd" > incarnation and allow Qjackctl and legacy control applications to be used > with it. The "D-Bus" one would package the "jackdbus" incarnation, and > provide D-Bus bas control applications (patchage, ladi tools....). The > problem of this strategy is that..., it is a kind of complete failure > regarding the way jack is supposed to be distributed. It may even get > worse if a new "jackosc" incarnation (a one that would allow to control > the server using OSC) appears a some point in the future... > > 5) Another idea would be improve the "choice of auto-start strategy" > by providing a runtime choice for that: a way for the user to select > between the "classic", "D-Bus", "OSC", strategy once globally for a given > working session... > > 5) Another idea would be be to completely drops the "auto-start" > strategy...This way we don't have multiple strategy anymore, and solve > most of the problems... but loose a feature. > > Comments? >
(there are two 5)'s above but i'll refer to the first one) i vote for the 5) auto-start strategy. user selects which one he/she prefers. the default should be "classic" and i would add fallback to "d-bus" and/or "osc" whatever. i still fail to see the problem of honoring .jackdrc if it exists on your home directory. ie. if .jackdrc exists then do the "classic" auto-start; if not, check d-bus service; etc. byee -- rncbc aka Rui Nuno Capela [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
