Re: [LAD] jackd/jackdbus : D-Bus or not D-Bus...

On Tuesday 19 May 2009 04:38:24 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.

So, when the classic jackd is running and you do a ps ax | grep jack what do
you see?

And when the new jackdbus is running and you do a ps ax | grep jack what do
you see?
>
> 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

I don't think anyone has yet stipulated that this must be a compile time
option and not a run time config file option. Must it be a compile time
option?

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

What would happen if the jackdbus incarnation checked for an rc file on launch
and, if it found one, rewrote its own xml file to match before proceeding
with startup. Then on each change of its own xml file, it could rewrite the
rc file. Would that give a quick and dirty fix to this issue until a better
solution is found?
>
> 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...

What are the problems with this idea? For packages made by one person and
installed by others, aren't runtime choices better and more flexible than
compile time choices? (Generally...)
>
> 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?

I think we may not have paid enough attention to what others have been saying
in this thread. Myself included. And perhaps this has *"extended"* the
discussion.
>
> Stephane

all the best,

drew

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue May 19 16:15:04 2009