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

Stéphane Letz letz at grame.fr
Tue May 19 08:38:24 UTC 2009

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.



More information about the Linux-audio-dev mailing list