On Mon, 18 May 2009 17:36:11 +0400, alex stone wrote:
Ok, let's stop dancing then :) Let me try to explain that dbus here is not
the center of what has changed in JACK2.
The new feature in JACK2 is the control API. That is: a *C control API*.
Now it is very important to read the previous sentence over and over again.
Once the dbus keyword has disappeared of your focus, read on.
So, this C/C++ control API allows one to start/stop jack, configure it, and
manage connections in between clients. This C control API allows one to
control the server entirely in a cleaner fashion than what was used before.
jackd makes use of this new API.
And now the fun part. Say we want to control JACK with hmm... OSC. One will
program something called jackosc that will *expose* the jack control API
through a small OSC server. it's as simple as some python bindings for
Now that I have explained most of the new stuff in JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
> Is there going to be a non dbus jack version going forward?
You should already have the answer : there is and there will always be. The
JACK control API is the core and is C, dbus is just an interface, just like
any other kind of interface would be (OSC, HTTP, whatever...).
> And please assume here i'm talking about a complete
Who wants to maintain to trees just to hide a compile time option ? what if
we really add jackosc to the list ? Should that be a third tree ?
Nedko, Stéphane: If I made any mistakes in my explanations, please correct
Participez au black-out anti-HADOPI :
Linux-audio-user mailing list