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
>> between
>> the "classic", "D-Bus", "OSC", strategy once globally for a given
>> working
>> session...
>
> 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.
>
> Ciao,
>
> --
> FA
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 ?
Stephane
_______________________________________________
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:03 2009
This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 16:15:03 EEST