Re: Server control plug-ins proposal

Le 30 juin 09 à 23:39, Nedko Arnaudov a écrit :



First let me explain the latest state of this "control" plugin  
implementation (for all jack-dev list readers...). DBus is used in the  
current JACK2 code base in several places:

- in the "jackdbus" incarnation of the JACk server

- in the ALSA backend, where we use audio card "acquire/release" DBus  
code (in collaboration with PulseAudio developers) so that JACK can  
reliably access the audio card.

- in libjack.so code when a client require to "autostart" the server.

- Lennart also recently proposed to add a DBus based call so that the  
JACK server notify other processes using DBus when starting or  
stopping. This would allows PulseAudio to automatically load/unload PA  
<==> JACK bridges when needed.

So basically the current DBus code appears at several places in the  
JACK2 tree and is "conditionnally" compiled.The purpose of  the  
"control" plugin is to have all this kind of code at a *unique* place,  
be compiled as a separated component, and be loadable on request to  
add specific features into the JACK server.

Control plugins are compiled as "jack_control_XXX" named shared  
libraries. They are currently two kinds of plugin:

- auto loaded ones: they are called "jack_control_auto_XXX" and will  
be *always* be loaded by the server (for example I now use this  
feature in a "jack_control_auto_osx" that notify other audio  
components in the system like JackRouter or JackPilot on OSX when the  
JACK server starts/stops, and this is done using Apple specific  
notification IPC code..)

- standard ones: the way to load them is to use the new -C parameter  
in the jackd command like so that we can use for instance: "jackd -C  
dus -d alsa -p 512" to start the server and have the DBus control  
plugin loaded.

Here is the currently defined "control" plugin API:

/**
  * Called by the server after loading the plug-in.
*/
bool jackctl_plugin_initialize(jackctl_server_t * server, const char*  
driver_name);

/**
  * Called by the server before unloading the plug-in.
*/
bool jackctl_plugin_finish();

/**
  * Called just after starting the server.
*/
bool jackctl_plugin_server_start(const char* server_name);

/**
  * Called just after stopping the server.
*/
bool jackctl_plugin_server_stop(const char* server_name);

/**
  * Called in libjack.so to start the server.
*/
bool jackctl_plugin_server_autostart(const char* server_name);

/**
  * Called before starting the backend.
*/
bool jackctl_plugin_backend_start(const char* device_name);

/**
  * Called before stopping the backend.
*/
bool jackctl_plugin_backend_stop(const char* device_name);


How is the control plugin code used ?

- if the plugin is an auto loaded one, it will be loaded and it's API  
called at the appropriate time (when the server starts, possibly when  
the audio backend starts...)

- for the server "autostart" feature, the server scans *all* available  
control plugin to find if one has an "jackctl_plugin_server_autostart"  
API implemented (done in start_server in JackPosixServerLunahc.cpp file)


Please test the lastest bc3ad833b6262e565483f7912a75c5f895dec6e5 commit.

  I just desactivated the ALSA backend  "acquire/release" DBus code.  
The reason is that with the Dbus control plugin, all calls to DBus API  
are not done in a *unique* thread anymore. The DBus message management  
call done in the "dbus_thread" function (in dbusplugin.ci file) is  
using dbus_connection_read_write_dispatch and this does not work  
correctly if another thread (like the main on..) is calling part of  
our control API (like jackctl_plugin_backend_start/
jackctl_plugin_backend_stop when starting/stopping the JACK server. As  
far as I could understand the entire DBus main loop should be  
rewritten  (that is not using "dbus_connection_read_write_dispatch"  
anymore)....; but I don't now how to do that right now.

That said, the bc3ad833b6262e565483f7912a75c5f895dec6e5 should work a  
bit better (without this  ALSA backend  "acquire/release" DBus code  
for now)

>
>> 2. Two widesread applications, ardour and qjackctl write jackdrc
>> directly. This desecrates the tradition that assumes jackdrc file is
>> written by a human and is read by the software. Also it implies race
>> condition because there is NO read/write locking mechanism
>> used. jackdrc reader may get inconsistent data during write. Two
>> simultaneous writters may corrupt the file.
>
> Not solved.

There is nothing done related to the fact DBus based code uses its own  
way (XML based) to deal with server state and the old .jackdrc file.

To be clear on the ambition of this control plugin system: it cannot  
solve all the problems that were identified during the DBus  
discussion. The point is to better separate the control code in a  
separated component. Then the way it is supposed to be used in the  
following:

1) we should be able to completely remove the DBus code from the JACK  
code base. The JACK2 code base then would be released in a "standard"  
package containing "jackd" (and stuff..) *only*. This package can be  
used with Qjackctl exactly as it was before.

Guardians stay happy.

2) DBus control plugin would be compiled separately (it depends on  
*public* JACK headers only): a specific package would be defined.  
People who want to use the Dbus based control system install this  
package on top of "standard" JACK2 package. The package puts  
"jack_control_dbus" at the appropriate place. Then people are supposed  
to use DBus based control tools (ladi tools, jack_control python  
tool...). Since the "jack_control_dbus" plugin is installed, the  
"autostart" mode will correctly use the Dbus based autostart mode.  
Qjackctl can still be used, but yes this may result in an inconsistent  
state (but well the "jackd / jackdbus " current situation is *not*  
better in this regard...).

Rebels are happy also.

As I said, the current "http://repo.or.cz/w/jack2.git?a=shortlog;h=refs/heads/controlplugin 
" implemntation still has two main issues:

- DBus calls cannot be mixed, the  
"dbus_connection_read_write_dispatch" has to be replace with a  
rewritten DBus main loop.

- they are still inconsistency between the state kept by the DBus XML  
based code and the state used by the server at a given time. I  
consider this as part os a more general issue which is : do we want  
JACK to define a new API (the so called "config" API) that would allow  
to kept and control the server state at a *centralized* place?

I think we would first try to get a common understanding of the  
proposed control plugin scheme before moving on.

Stephane





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