[LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
letz at grame.fr
Tue May 19 09:44:13 UTC 2009
Le 19 mai 09 à 11:30, Fons Adriaensen a écrit :
> On Tue, May 19, 2009 at 10:38:24AM +0200, Stéphane Letz wrote:
>> 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
>> the "classic", "D-Bus", "OSC", strategy once globally for a given
> I will be writing an OSC layer (on top of the existing interfaces)
> because I badly need a soluting for scriptable (i.e. non-interactive)
> remote control of jackd.
> It will be non-invasive and just use the existing jackd/libjack
> without modifying anything. There will be no such thing as an
> 'OSC autostart strategy'.
> IMHO dbus could be just the same. This would mean that
> any advantages it may bring will be there only if app
> writers start using it *explicitly* by directly calling
> dbus instead of a jackd/libjack C API function.
> Which just means that dbus will have to prove its value
> in the market instead of being forced onto everyone,
> and that is a Good Thing (TM).
> Support for accessing dbus could even be integrated in
> libjack (or some new library) as long as it just adds
> ew calls and does not modify the action of any existing
> C API call.
It seems you really don't want to see that using this
"jack_client_open does a fork+exec call to launch jackd with the ./
jackdrc file" has been completely *hard coded* in libjack from day
one! And is a really strong constraint for any possible new way of
controlling the server.
The discussion is now: do we keep this "hard coded thing in libjack"
or do we try to relax it a bit ?
More information about the Linux-audio-dev