DBus server control : description of 2 proposals

Up to now, we have 2 proposals for the DBus based JACK server control.  
Please contribute to any points if you think something is missing or  
incorrect.

Thanks.

The 2 proposal (especially the second) may still have implementation  
issues, but I hope they are advanced enough for some comparison to  
take place.

Stephane

----------------------------------------------------------------

Proposal 1 (Nedko):

1) a new incarnation of JACK server is called "jackdbus" : this new  
exe in controlable from others processes using the so called control  
API exposed using DBus IPC. A simple python "jack_control" is given as  
a way to control the JACK server. Others tools are "LADI tools" and  
LASH.

2) DBus code that was used to cleanly interact with PulseAudio (audio  
card acquire/release scheme) can (has) be moved in jackdbus code.

3) the jackdbus code interact with JACK using pure public JACK headers  
and linking to the server side library called "libjackserver.so". Il  
is right now in the JACK2 source tree but could be technically  
separated (It somewhat has the same status of any code that use JACK  
API (server or client side) using public JACK headers and linking  
libraries).

4) jackdbus uses its own XML based system to save/restore JACK server  
state (JACK server parameters, chosen backend, parameters of the  
backend...). Thus the ~/.jackdrc state is not used anymore.

5) clients that want to autostart have to control the JACK server  
using the DBus based controler. Thus the old fork+exec model to start  
the JACK server from libjack.so cannot be used anymore.  The latest  
proposal is to use a command like "dbus-send --session --print-
reply=yes --dest=org.jackaudio.service /org/jackaudio/Controller  
org.jackaudio.JackControl.StartServer" in ~/.jackdrc to start the JACK  
server with the help of DBus based controler. A request is done to  
keep compiled time option to be able to have DBus controler accessed  
directly in libjack.so.

6) mixing legacy "jackd" incarnation of JACK server with "jackdbus" in  
the receipe for problems. Indeed depending of which controler tool is  
used to start the JACK server (that is legacy Qjackctl controler or  
new "jack_control" or similar), the "jackd" or "jackdbus" incarnation  
of the JACK server will be started. Consequently the server starting  
state will be one that each server incarnation is used.

7) because of potential problems in the combined use of "jackd" and  
"jackdbus", a fined-grained packaging strategy has to be defined to  
avoid installing "jackd" and "jackdbus" at the same time. Controler  
tools (legacy Qjackctl) or DBus based one have to be installed and  
their dependency controled depending of the installed JACK server  
incarnation. This strategy is explained here : http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

8) developing others incarnation of JACK server, like "jackOSC" (to be  
controled using OSC) would probably require the same kind of packaging  
strategy.


----------------------------------------------------------------


Proposal 2 (Stephane):

1) a unique "jackd" incarnation of JACK server stays. A new "control  
plugin" scheme is added. A control plugin goal is to expose the so  
called control API using a given IPC model. Two different model of  
control plugin are currently defined: those named  
"jack_control_auto_XX" are automatically loaded by the jackd process.  
Those named "jack_control_XX" are to be loaded on request using a new  
"-C" parameter in jackd command line.

2)  jackdbus code from proposal 1 has been refactored in a  
"dbusplugin" file to be compiled in the "jack_control_dbus" plugin.  
This plugin expose the control API using DBus IPC and contains the  
code to cleanly interact with PulseAudio (audio car acquire/release  
scheme). A simple python "jack_control" is given as a way to control  
the JACK server. Others tools are "LADI tools" and LASH.

3) the "dbusplugin" code interacts with JACK using pure public JACK  
headers and linking to the server side library called  
"libjackserver.so". Il is right now in the JACK2 source tree but could  
be technically separated (It somewhat has the same status of any code  
that use JACK API (server or client side) using public JACK headers  
and linking libraries).

4) jackd process can still be used the legacy way and using the new -C  
parameter to load a control plugin. Thus for instance "jackd -C dbus -
R -d alsa -p 512" can be used.

5) JACK DBus service does now "jackd -C dbus" to start the server and  
load the dbus plugin. Then actual control of the server is done  
through DBus IPC.

4) for clients autostart feature, control plugin can define a  
"jackctl_plugin_server_autostart" to be used in libjack.so JACK server  
starting code. If several installed control plugin have the  
"jackctl_plugin_server_autostart" , then one of them will be used  
(typically the first found one) . Thus having several installed  
control plugin with the autostart feature is potentially problematic.

5) the proposed packages scheme is the following:
       
        - a standard JACK2 package is defined; is contains "jackd,  
libjack.so, libjackserver.so headers, tools.... It is the exact same  
packaging as legacy JACK. It is then  supposed to be used with legacy  
controler like Qjackctl

        - an additional package contains "jackd_control_dbus.so" and  
"jack_control" DBus based controler to be installed on top of standard  
package. It is then supposed to be used with new DBus based controlers.

6) other control IPC would typically be implemented in additional  
control plugins: like jack_control_osc" for an OSC based controler. As  
explained in 4), if several controler are installed at the same time  
over a  standard JACK2 package, then the "autostart" behaviour is not  
clearly defined.


Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org