[LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
marco at marcochapeau.org
Tue May 19 09:46:59 UTC 2009
On Tue, 19 May 2009 10:38:24 +0200, Stéphane Letz <letz at grame.fr> wrote:
> 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...
And we will all agree that this would be a packaging disaster. I package
jack for gentoo pro-audio, and I really don't know how I'd handle this one.
> 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...
To me, this one is the cleanest of all, and would allow to keep auto-start
for those who like it with the flavor of their choice (and eventually
disable it for those who don't ?)
> 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.
Last resort but if it comes down to this, I can handle my idea of
auto-start directly inside LADITools using dbus calls. although it wouldn't
be as good as the "any client can auto-start jack" paradigm.
Participez au black-out anti-HADOPI :
More information about the Linux-audio-dev