Server control plug-ins proposal

[Stéphane Letz]

Hi all,

Here is a patch that implements "Server control plug-ins" in JACK2  
SVN. The idea is to appease the DBus "guardians/rebels" war by cleanly  
separating the DBus code from the JACK2 code base. The proposed model  
hopefully helps without doing to much deep changes in the server code:

- a "control plug-in" is loaded in the server process, uses the  
Control API to control the server and possibly expose this API to  
external process using it's chosen IPC model.

- control plug-ins are named "jack_control_XXX" and are placed in the  
standard /usr/lib/jack folder where backends and internal clients are  
already placed.

- when the "jackd" process starts, it uses the parameters as usual,  
starts the server with the given parameters, but also scans in the /
usr/lib/jack folder, and loads and activates all available control  
plug-ins.

- if "jackd" is started without any parameter, then it just loads and  
activates all available control plug-ins  (see later).

- the "jackdbus" exe has been removed (see later).

Right now two plug-ins have been developed:

- on OSX, the "jack_control_osx"  plug-in notify others process when  
the JACK server starts and stops (using OSX specific IPC). This allows  
to remove long standing OSX specific code from the jackdmp.cpp file  
(that one that implements "jackd" exe). Nedko should be happy now.

- the "jack_control_dbus"  plug-in is the "jackbus.c" code reworked a  
bit to be used as a plug-in. The DBus dependancy that was done in  
libjack (when compiled in DBus mode) has been removed. Now an auto-
starting client launches "jackd" (possibly with parameters  
from .jackdrc) as it was before. The DBus service that was described  
in "org.jackaudio.service" file is no more "jackdbus", but simply  
"jackd".


To test:
======

./waf configure --dbus --classic, on OSX both jack_control_osx" and  
"jack_control_dbus" are compiled, on Linux only  "jack_control_dbus"  
is compiled.

When starting "jack" (either in a terminal or using Qjackctl) the  
"jack_control_dbus" control plug-in will be activated. The python  
"jack_control" will see the running "jackd" and allow to control it.  
If a DBus application is started first, then it will activate the  
"org.jackaudio.service" service that will simply launch "jackd"  
without parameters.


Knows problems, limitations:
=======================

- since the DBus code (now in "jack_control_dbus") uses it's own  
server setting format (XML file), they are still state coherency  
issues between the state kept in this XML file and the state used by  
the running server. A possible solution would be for the  
"jack_control_dbus" plug-in to get the state from the running server  
and save it in it's own format. But Nedko can comment more on that  
specific point.

- all loaded control plug-ins will get a pointer on the running server  
in their initialize function. So all control plug-ins see and control  
the *same* unique server. There is no "coherency" control between what  
each plug-in does on the server. (The model is kept simple for now...)

- they are probably still some bugs...

Future:
=======

- this model can be extended quite naturally if we finally decide to  
also have the control API available on client side (available using  
libjack.so). We would need to develop a "jack_control_ipc" kind of  
plug-in to expose this API on client side by extending current server/
client IPC.

Comments, suggestions, improvements welcome!

Stéphane

Patch : http:www.grame.fr/~letz/controlplug.patch

New global model : http:www.grame.fr/~letz/jackcontrol4.pdf
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

On Wed, Jun 03, 2009 at 05:03:15PM +0200, Stéphane Letz wrote:

> Hi all,
>
> Here is a patch that implements "Server control plug-ins" in JACK2 SVN. The
> idea is to appease the DBus "guardians/rebels" war by cleanly separating
> the DBus code from the JACK2 code base. The proposed model hopefully helps
> without doing to much deep changes in the server code:
>
> - a "control plug-in" is loaded in the server process, uses the Control API
> to control the server and possibly expose this API to external process
> using it's chosen IPC model.

hmm... you load the control plugins after server start.
is that necessary ?

if they were loaded earlier, they could even change some configuration
values. but this would of course open the issue of fighting plugins.
maybe its a can of worms you dont want to open ?

hmm... it seems i am overlooking something here.
maybe jack_controller_settings_init() is doing something similar.

i dont completely see how the config functionality of the old dbus
implementation is working now.

>
> - control plug-ins are named "jack_control_XXX" and are placed in the
> standard /usr/lib/jack folder where backends and internal clients are
> already placed.
>
> - when the "jackd" process starts, it uses the parameters as usual, starts
> the server with the given parameters, but also scans in the /usr/lib/jack
> folder, and loads and activates all available control plug-ins.
>
> - if "jackd" is started without any parameter, then it just loads and
> activates all available control plug-ins  (see later).
>
> - the "jackdbus" exe has been removed (see later).
>
> Right now two plug-ins have been developed:
>
> - on OSX, the "jack_control_osx"  plug-in notify others process when the
> JACK server starts and stops (using OSX specific IPC). This allows to
> remove long standing OSX specific code from the jackdmp.cpp file (that one
> that implements "jackd" exe). Nedko should be happy now.
>
> - the "jack_control_dbus"  plug-in is the "jackbus.c" code reworked a bit
> to be used as a plug-in. The DBus dependancy that was done in libjack (when
> compiled in DBus mode) has been removed. Now an auto-starting client
> launches "jackd" (possibly with parameters from .jackdrc) as it was before.
> The DBus service that was described in "org.jackaudio.service" file is no
> more "jackdbus", but simply "jackd".

>
> Knows problems, limitations:
> =======================
>
> - since the DBus code (now in "jack_control_dbus") uses it's own server
> setting format (XML file), they are still state coherency issues between
> the state kept in this XML file and the state used by the running server. A
> possible solution would be for the "jack_control_dbus" plug-in to get the
> state from the running server and save it in it's own format. But Nedko can
> comment more on that specific point.

if we find out how to prevent plugin config fighting, the plugin could
configure the server_ctl before its started.

is the libjackconfig idea still in discussion ?

>
> - all loaded control plug-ins will get a pointer on the running server in
> their initialize function. So all control plug-ins see and control the
> *same* unique server. There is no "coherency" control between what each
> plug-in does on the server. (The model is kept simple for now...)

i think a single lock for the whole control API and control plugins
"playing nice" should be enough.

some sort of callback or callbacks, when server state is changed, should
be enough, to make it possible, for many plugins to control a single
server.

multiple plugins
is a cornercase we should not put too much energy into (iE no fine
grained locking and multiple callbacks.)

maybe even an rw lock on the control API ? release of w lock triggers
callback. and plugins know something changed.

>
> - they are probably still some bugs...
>
> Future:
> =======
>
> - this model can be extended quite naturally if we finally decide to also
> have the control API available on client side (available using libjack.so).
> We would need to develop a "jack_control_ipc" kind of plug-in to expose
> this API on client side by extending current server/client IPC.
>
> Comments, suggestions, improvements welcome!
>
> Stéphane
>
> Patch : http:www.grame.fr/~letz/controlplug.patch
>
> New global model : http:www.grame.fr/~letz/jackcontrol4.pdf
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 3 juin 09 à 20:27, torbenh@... a écrit :

> On Wed, Jun 03, 2009 at 05:03:15PM +0200, Stéphane Letz wrote:
>> Hi all,
>>
>> Here is a patch that implements "Server control plug-ins" in JACK2  
>> SVN. The
>> idea is to appease the DBus "guardians/rebels" war by cleanly  
>> separating
>> the DBus code from the JACK2 code base. The proposed model  
>> hopefully helps
>> without doing to much deep changes in the server code:
>>
>> - a "control plug-in" is loaded in the server process, uses the  
>> Control API
>> to control the server and possibly expose this API to external  
>> process
>> using it's chosen IPC model.
>
> hmm... you load the control plugins after server start.
> is that necessary ?
>
> if they were loaded earlier, they could even change some configuration
> values. but this would of course open the issue of fighting plugins.
> maybe its a can of worms you dont want to open ?

Well the idea is that the parameters given to jackd takes precedences  
over any plug-in kept config state. (see later libjackconfig part...)


>
> hmm... it seems i am overlooking something here.
> maybe jack_controller_settings_init() is doing something similar.
>
> i dont completely see how the config functionality of the old dbus
> implementation is working now.

Not working in the sense that DBus control plug-in does not restore  
it's state. (see later libjackconfig part...)

>
>>
>> - control plug-ins are named "jack_control_XXX" and are placed in the
>> standard /usr/lib/jack folder where backends and internal clients are
>> already placed.
>>
>> - when the "jackd" process starts, it uses the parameters as  
>> usual, starts
>> the server with the given parameters, but also scans in the /usr/
>> lib/jack
>> folder, and loads and activates all available control plug-ins.
>>
>> - if "jackd" is started without any parameter, then it just loads and
>> activates all available control plug-ins  (see later).
>>
>> - the "jackdbus" exe has been removed (see later).
>>
>> Right now two plug-ins have been developed:
>>
>> - on OSX, the "jack_control_osx"  plug-in notify others process  
>> when the
>> JACK server starts and stops (using OSX specific IPC). This allows to
>> remove long standing OSX specific code from the jackdmp.cpp file  
>> (that one
>> that implements "jackd" exe). Nedko should be happy now.
>>
>> - the "jack_control_dbus"  plug-in is the "jackbus.c" code  
>> reworked a bit
>> to be used as a plug-in. The DBus dependancy that was done in  
>> libjack (when
>> compiled in DBus mode) has been removed. Now an auto-starting client
>> launches "jackd" (possibly with parameters from .jackdrc) as it  
>> was before.
>> The DBus service that was described in "org.jackaudio.service"  
>> file is no
>> more "jackdbus", but simply "jackd".
>
>
>>
>> Knows problems, limitations:
>> =======================
>>
>> - since the DBus code (now in "jack_control_dbus") uses it's own  
>> server
>> setting format (XML file), they are still state coherency issues  
>> between
>> the state kept in this XML file and the state used by the running  
>> server. A
>> possible solution would be for the "jack_control_dbus" plug-in to  
>> get the
>> state from the running server and save it in it's own format. But  
>> Nedko can
>> comment more on that specific point.
>
> if we find out how to prevent plugin config fighting, the plugin could
> configure the server_ctl before its started.
>
> is the libjackconfig idea still in discussion ?

Yes, I think we should now works on libjackconfig idea. We could have  
the following stategy:

1) jackd started with parameters ==> those parameters are used, and  
saved as a so called "default" state using libjackconfig

3) jacks started without parameters ==> any control plug-in should  
load the so called "default" state using libjackconfig and configure  
the server with it.

>
>>
>> - all loaded control plug-ins will get a pointer on the running  
>> server in
>> their initialize function. So all control plug-ins see and control  
>> the
>> *same* unique server. There is no "coherency" control between what  
>> each
>> plug-in does on the server. (The model is kept simple for now...)
>
> i think a single lock for the whole control API and control plugins
> "playing nice" should be enough.
>
> some sort of callback or callbacks, when server state is changed,  
> should
> be enough, to make it possible, for many plugins to control a single
> server.
>
> multiple plugins
> is a cornercase we should not put too much energy into (iE no fine
> grained locking and multiple callbacks.)
>
> maybe even an rw lock on the control API ? release of w lock triggers
> callback. and plugins know something changed.
>
>

Yep. Something like that.

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

[Marc-Olivier Barre-3]

On Wed, 3 Jun 2009 20:59:11 +0200, Stéphane Letz <letz@...> wrote:

> Le 3 juin 09 à 20:27, torbenh@... a écrit :
>
>> On Wed, Jun 03, 2009 at 05:03:15PM +0200, Stéphane Letz wrote:
>>> Knows problems, limitations:
>>> =======================
>>>
>>> - since the DBus code (now in "jack_control_dbus") uses it's own  
>>> server
>>> setting format (XML file), they are still state coherency issues  
>>> between
>>> the state kept in this XML file and the state used by the running  
>>> server. A
>>> possible solution would be for the "jack_control_dbus" plug-in to  
>>> get the
>>> state from the running server and save it in it's own format. But  
>>> Nedko can
>>> comment more on that specific point.
>>
>> if we find out how to prevent plugin config fighting, the plugin could
>> configure the server_ctl before its started.
>>
>> is the libjackconfig idea still in discussion ?
>
> Yes, I think we should now works on libjackconfig idea. We could have  
> the following stategy:
>
> 1) jackd started with parameters ==> those parameters are used, and  
> saved as a so called "default" state using libjackconfig
>
> 3) jacks started without parameters ==> any control plug-in should  
> load the so called "default" state using libjackconfig and configure  
> the server with it.

I'd add a 2) in between that would say :

2) jackd started with a request for a specific profile other than default
-> parameters matching this profile are fetched from a libjackconfig
managed config repo

Would this do everything we dreamed of ?

--
Marc-Olivier Barre
XMPP ID : marco@...
www.MarcOChapeau.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

Hi,

There are two problems that i see with this implementation.

When dbus session bus daemon autoactivates jack controller it gets
started but jackdbus log file does not contain the log messages from
jack server. It contains this instead:

Thu Jun  4 10:32:15 2009: ------------------
Thu Jun  4 10:32:15 2009: Controller activated. Version 1.9.3 (3557M)
Thu Jun  4 10:32:15 2009: dbus : thread started...
Thu Jun  4 10:32:37 2009: dbus : thread exit...
Thu Jun  4 10:32:37 2009: Controller deactivated.

This is major drawback. I don't know yet why it happens.

The second problem is that autoactivation does not work. What I did:

 * autoactivate (reactivate in laditools) jack controller dbus
   object. laditools display that server is stopped (this is what should
   happen).
 * start jack client app that tries to autoactivate.

What happens:

In log file:
Thu Jun  4 10:34:05 2009: ------------------
Thu Jun  4 10:34:05 2009: Controller activated. Version 1.9.3 (3557M)
Thu Jun  4 10:34:05 2009: ERROR: Requested D-Bus service name already exists

In process list:
nedko     5741  0.0  0.1  15072  2540 ?        Ssl  10:32   0:00 /usr/bin/jackd
nedko     5829  0.4  0.4  50224  9680 ?        Ssl  10:44   0:00 /usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 3 -r 48000 -p 512 -d hw:0,0

LADI tools report that JACK server is stopped when it was
(auto)started. They use the first jackd. JACK controller dbus object is
singleton. Thus the dbus error in the log file.

These problems aside, I think this is a better approach than using two
IPC layers between laditools and jack server. I still think that it can
be even simpler if client control API is launching the server in IPC
specific way (what i suggested instead).

Given that you wont accept the better (IMHO) solution I think the above
problems can fixed:

 1. plugin needs to configure the log callback of the jack server.
 2. jackd should refuse to start when jackdbus controller is already
    running.
 3. when dbus is enabled at configure stage, the resulting libjack
    must first try to start jack server through dbus.

I just saw another bug. If jack is configured with dbus only. you get no
jack server at all because jackd is not installed and jackdbus is
removed.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Nedko Arnaudov]

Marc-Olivier Barre <marco@...> writes:

> I'd add a 2) in between that would say :
>
> 2) jackd started with a request for a specific profile other than default
> -> parameters matching this profile are fetched from a libjackconfig
> managed config repo
>
> Would this do everything we dreamed of ?

I personally dream about settings not persisted in server at all. I
dream about LASH studio sessions. Studio sessions are abstraction
for normal jack clients that see virtual studio ports (like the Fons'es
detached ports). Studio session/layer itself contains mapping between
virtual persistent ports and hardware ports. It may contain crossovers
and equalizers. And it contains JACK server settings.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Stéphane Letz]

Le 4 juin 09 à 10:01, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
> Hi,
>
> There are two problems that i see with this implementation.
>
> When dbus session bus daemon autoactivates jack controller it gets
> started but jackdbus log file does not contain the log messages from
> jack server. It contains this instead:
>
> Thu Jun  4 10:32:15 2009: ------------------
> Thu Jun  4 10:32:15 2009: Controller activated. Version 1.9.3 (3557M)
> Thu Jun  4 10:32:15 2009: dbus : thread started...
> Thu Jun  4 10:32:37 2009: dbus : thread exit...
> Thu Jun  4 10:32:37 2009: Controller deactivated.
>
> This is major drawback. I don't know yet why it happens.

This should be corrected now.

>
>
> The second problem is that autoactivation does not work. What I did:
>
> * autoactivate (reactivate in laditools) jack controller dbus
>   object. laditools display that server is stopped (this is what  
> should
>   happen).
> * start jack client app that tries to autoactivate.
>
> What happens:
>
> In log file:
> Thu Jun  4 10:34:05 2009: ------------------
> Thu Jun  4 10:34:05 2009: Controller activated. Version 1.9.3 (3557M)
> Thu Jun  4 10:34:05 2009: ERROR: Requested D-Bus service name  
> already exists
>
> In process list:
> nedko     5741  0.0  0.1  15072  2540 ?        Ssl  10:32   0:00 /
> usr/bin/jackd
> nedko     5829  0.4  0.4  50224  9680 ?        Ssl  10:44   0:00 /
> usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 3 -r 48000 -
> p 512 -d hw:0,0
>
> LADI tools report that JACK server is stopped when it was
> (auto)started. They use the first jackd. JACK controller dbus object  
> is
> singleton. Thus the dbus error in the log file.

OK. I've experimented the following:

- control plugin  has to define : "jackctl_plugin_initialize" and  
"jackctl_plugin_finish" to be used on server side.

- control plugin now (possibly) defines also a  
"jackctl_plugin_autostart" to be used on client side (that is  
libjack.so). When client autostart, the server launcher scan control  
plug-ins and call the  "jackctl_plugin_autostart"  function if  
available.

So right now the "jack_control_dbus"  control plugin defines this  
"jackctl_plugin_autostart"  to access jackd server using DBus. This  
way we do not have those 2 different launches of jackd. If no control  
plugin defines a "jackctl_plugin_autostart" function, then fork-exe  
method is used to start the server.

This way all code that is "part of the control", that is "exposing the  
control API using a given IPC" and "autostarting the server using a  
given IPC"  is completely located at a unique place inside the control  
plugin.

Not obviously, this makes sense only if there is only *one*  
autostarting control plugin at a given time...

>
>
> These problems aside, I think this is a better approach than using two
> IPC layers between laditools and jack server. I still think that it  
> can
> be even simpler if client control API is launching the server in IPC
> specific way (what i suggested instead).
>
> Given that you wont accept the better (IMHO) solution I think the  
> above
> problems can fixed:
>
> 1. plugin needs to configure the log callback of the jack server.
> 2. jackd should refuse to start when jackdbus controller is already
>    running.
> 3. when dbus is enabled at configure stage, the resulting libjack
>    must first try to start jack server through dbus.
>
> I just saw another bug. If jack is configured with dbus only. you  
> get no
> jack server at all because jackd is not installed and jackdbus is
> removed.
>

Yes, the wscipt are not corrected yet, both --dbus and --classic have  
to be used for now.

Can be tested here :  http://repo.or.cz/w/jack2.git controlplugin branch

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

[Nedko Arnaudov]

Hi,

I've tested the controlplugin branch at
9c8728a6a00923b7dbcecb1da632a8fe9da89010.

I get no messages in the log file at all.

At some earlier version (93a9f176212cce84799258df6064e1b789068934) I had
messages in the log file but server settings are not read. I had the
dummy driver used. This is very strange because I have alsa driver
selected in both setting files, ~/.config/jack/conf.xml and ~/.jackdrc

I think it is still the case but I cant be completely sure because I
have no log anymore :(
What I can see through wmladi is that I get "wrong" latency used and no
realtime being used.

I still dont get how this plugin stuff helps. Instead of "jackdbus auto"
process you get "jackd -C dbus" process.

Let me match the controlplugin branch status against problems I've
identified in my original guardians/rebels mail:

> 1. jackdbus uses different settings storage. Because guardians like the
> way it works for them, they are not fascinated about this. Rebels
> however clearly see that jackdrc format was a mistake. It is not
> settings format but a shell script (and some guardians use it like
> shell script). Moreover jackdrc format is not hierarchical. It does not
> allow multiconfigs. OTOH having JACK settings in two places is BAD. If
> one has mixed jackd+jackdbus system, both will be used. Simple convert
> during a transistion is not fixing the problem because both jackd and
> jackdbus are installed on the system.

Now it is even worse. I get wrong settings used even when they are right
in both places. May be this is just a little bug somewhere though.

> 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.

> 3. Two widesread applications, ardour and qjackctl launch jackd
> manually. Thus they can't start JACK server if it is implemented
> differently. Thus they can't start JACK server in a LADI (jackdbus)
> system.

Not solved too. They start jackd without "-C dbus", thus laditools and
other jackdbus control apps dont see the jack server as running but they
see the other jackd instance, the one with "-C dbus" and it reports the
wrong state of the jack virtual studio.

> 4. When qjackctl is not used, guardians tend to check whether server is
> running by checking for running jackd process through ps or some
> process monitor like htop. This will not work when they are in the
> dbus rebel's camp because there may be jackdbus process but this is not
> a proof that jack server is running.

Not solved. "jackd -C dbus" and "jackdbus" both suggest that jack is
tainted by the dbus daemon and both are not indication whether jack
server is running.

> 5. Some guardinas are not happy with the fact that multiprofile setup
> is not possible with jackrc format. They clearly need this feature even
> if they dont like the dbus heresy.

If I got it right, not solved. Probably not topic of the controlplugin
branch though.

> 6. Some guardians are not happy with the fact that dbus rebels give
> some gifts to their followers. They want these gifts to be universal
> and available even to tradition piligrims.

If I got it right, not solved either. But maybe controlplugin
refactoring somehow will allow this. I have no strong opinion here
because I want multiple "studio abstractions" available as part of the
jack virtual studio. Current plan for the abstractions of studio setups
is to implement them as lash sessions that are loaded before loading the
normal lash session, be it song composition setup, recording setup for
particular song or live play setup.

I'd find it much more useful if veto stuff gets more push. It will ease
virtualization of the jack connections and thus will be one step toward
virtual studio setups.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Stéphane Letz]

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

> Hi,
>
> I've tested the controlplugin branch at
> 9c8728a6a00923b7dbcecb1da632a8fe9da89010.
>
> I get no messages in the log file at all.
>
> At some earlier version (93a9f176212cce84799258df6064e1b789068934) I  
> had
> messages in the log file but server settings are not read. I had the
> dummy driver used. This is very strange because I have alsa driver
> selected in both setting files, ~/.config/jack/conf.xml and ~/.jackdrc
>
> I think it is still the case but I cant be completely sure because I
> have no log anymore :(
> What I can see through wmladi is that I get "wrong" latency used and  
> no
> realtime being used.
>
> I still dont get how this plugin stuff helps. Instead of "jackdbus  
> auto"
> process you get "jackd -C dbus" process.

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)

>
> Let me match the controlplugin branch status against problems I've
> identified in my original guardians/rebels mail:
>
>> 1. jackdbus uses different settings storage. Because guardians like  
>> the
>> way it works for them, they are not fascinated about this. Rebels
>> however clearly see that jackdrc format was a mistake. It is not
>> settings format but a shell script (and some guardians use it like
>> shell script). Moreover jackdrc format is not hierarchical. It does  
>> not
>> allow multiconfigs. OTOH having JACK settings in two places is BAD.  
>> If
>> one has mixed jackd+jackdbus system, both will be used. Simple  
>> convert
>> during a transistion is not fixing the problem because both jackd and
>> jackdbus are installed on the system.
>
> Now it is even worse. I get wrong settings used even when they are  
> right
> in both places. May be this is just a little bug somewhere though.

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.

>
>> 3. Two widesread applications, ardour and qjackctl launch jackd
>> manually. Thus they can't start JACK server if it is implemented
>> differently. Thus they can't start JACK server in a LADI (jackdbus)
>> system.
>
> Not solved too. They start jackd without "-C dbus", thus laditools and
> other jackdbus control apps dont see the jack server as running but  
> they
> see the other jackd instance, the one with "-C dbus" and it reports  
> the
> wrong state of the jack virtual studio.
>
>> 4. When qjackctl is not used, guardians tend to check whether  
>> server is
>> running by checking for running jackd process through ps or some
>> process monitor like htop. This will not work when they are in the
>> dbus rebel's camp because there may be jackdbus process but this is  
>> not
>> a proof that jack server is running.
>
> Not solved. "jackd -C dbus" and "jackdbus" both suggest that jack is
> tainted by the dbus daemon and both are not indication whether jack
> server is running.
>
>> 5. Some guardinas are not happy with the fact that multiprofile setup
>> is not possible with jackrc format. They clearly need this feature  
>> even
>> if they dont like the dbus heresy.
>
> If I got it right, not solved. Probably not topic of the controlplugin
> branch though.
>
>> 6. Some guardians are not happy with the fact that dbus rebels give
>> some gifts to their followers. They want these gifts to be universal
>> and available even to tradition piligrims.
>
> If I got it right, not solved either. But maybe controlplugin
> refactoring somehow will allow this. I have no strong opinion here
> because I want multiple "studio abstractions" available as part of the
> jack virtual studio. Current plan for the abstractions of studio  
> setups
> is to implement them as lash sessions that are loaded before loading  
> the
> normal lash session, be it song composition setup, recording setup for
> particular song or live play setup.
>
> I'd find it much more useful if veto stuff gets more push. It will  
> ease
> virtualization of the jack connections and thus will be one step  
> toward
> virtual studio setups.

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

[Tinram]

Hi devs,

I've started to write a gui to starts/stops jack and deals with its
configuration but I stopped when the first discussion about
dbus started.

I'd like to add my (2 cents ?) "jack external client developer"
comments/opipion(/ideas ?):


- If jackd loads *every* installed plugins on startup, dbus plugin would
be available even if jackd is started by Ardour/QJackCtl... And if you
don't want it you don't install it and thats all. Using a Linux
distribution, jack_control would depend of a jack-plugin-dbus package
and it would be invisible for users.
Such a system solves Nedko Arnaudov points 2. and 3. no ?
*But* starting jackd through DBus isn't possible anymore...

- Stéphane Letz proposed, but it had not been discuss so much, a libjack
build-in multi-configs manager, to share configuration with every
control apps. I think it can solve few issues.
   Imagine we've got two files : one containing the current/default
config like the normal ~/jackdrc and an other one with is a databases of
user configurations (xml ?).
   A control app will just take one config from the database and write
it to ~/jackdrc and then ask jackd to start on a
common/shared-by-every-client way witch use ~/jackdrc. It could be a
fork+exec(jackd auto) for example. No need to use DBus (or whatever) for
starting up jackd.


That's just my vision of the problem...

Martin Blanchard  


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

[Stéphane Letz]

Le 1 juil. 09 à 12:51, Martin Blanchard a écrit :

> Hi devs,
>
> I've started to write a gui to starts/stops jack and deals with its
> configuration but I stopped when the first discussion about
> dbus started.
>
> I'd like to add my (2 cents ?) "jack external client developer"
> comments/opipion(/ideas ?):
>
>
> - If jackd loads *every* installed plugins on startup, dbus plugin  
> would
> be available even if jackd is started by Ardour/QJackCtl... And if you
> don't want it you don't install it and thats all. Using a Linux
> distribution, jack_control would depend of a jack-plugin-dbus package
> and it would be invisible for users.
> Such a system solves Nedko Arnaudov points 2. and 3. no ?
> *But* starting jackd through DBus isn't possible anymore...
>
> - Stéphane Letz proposed, but it had not been discuss so much, a  
> libjack
> build-in multi-configs manager, to share configuration with every
> control apps. I think it can solve few issues.
>   Imagine we've got two files : one containing the current/default
> config like the normal ~/jackdrc and an other one with is a  
> databases of
> user configurations (xml ?).
>   A control app will just take one config from the database and write
> it to ~/jackdrc and then ask jackd to start on a
> common/shared-by-every-client way witch use ~/jackdrc. It could be a
> fork+exec(jackd auto) for example. No need to use DBus (or whatever)  
> for
> starting up jackd.
>
>
> That's just my vision of the problem...
>
> Martin Blanchard
>

Not working because the "jackd" process may run without having the  
JACK server running.... For example if you use "jack_control status"  
then you see "jackd -C dbus" process, but  JACK server is still not  
running. Then if a client does autostart the server, it does not see  
any running JACK, then would do fork+exec and this would start a new  
"jackd"....

If the client call the autostart code that is available in the  
installed "jack_control_dbus" control plugin, then it works because it  
uses the DBus way of starting the server....

Not easy, but I could not find any simpler model up to now..

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

[Tinram]

Le mercredi 01 juillet 2009 à 15:29 +0200, Stéphane Letz a écrit :

>
> Le 1 juil. 09 à 12:51, Martin Blanchard a écrit :
>
> > Hi devs,
> >
> > I've started to write a gui to starts/stops jack and deals with its
> > configuration but I stopped when the first discussion about
> > dbus started.
> >
> > I'd like to add my (2 cents ?) "jack external client developer"
> > comments/opipion(/ideas ?):
> >
> >
> > - If jackd loads *every* installed plugins on startup, dbus plugin  
> > would
> > be available even if jackd is started by Ardour/QJackCtl... And if you
> > don't want it you don't install it and thats all. Using a Linux
> > distribution, jack_control would depend of a jack-plugin-dbus package
> > and it would be invisible for users.
> > Such a system solves Nedko Arnaudov points 2. and 3. no ?
> > *But* starting jackd through DBus isn't possible anymore...
> >
> > - Stéphane Letz proposed, but it had not been discuss so much, a  
> > libjack
> > build-in multi-configs manager, to share configuration with every
> > control apps. I think it can solve few issues.
> >   Imagine we've got two files : one containing the current/default
> > config like the normal ~/jackdrc and an other one with is a  
> > databases of
> > user configurations (xml ?).
> >   A control app will just take one config from the database and write
> > it to ~/jackdrc and then ask jackd to start on a
> > common/shared-by-every-client way witch use ~/jackdrc. It could be a
> > fork+exec(jackd auto) for example. No need to use DBus (or whatever)  
> > for
> > starting up jackd.
> >
> >
> > That's just my vision of the problem...
> >
> > Martin Blanchard
> >
>
>
> Not working because the "jackd" process may run without having the  
> JACK server running.... For example if you use "jack_control status"  
> then you see "jackd -C dbus" process, but  JACK server is still not  
> running. Then if a client does autostart the server, it does not see  
> any running JACK, then would do fork+exec and this would start a new  
> "jackd"....
>
> If the client call the autostart code that is available in the  
> installed "jack_control_dbus" control plugin, then it works because it  
> uses the DBus way of starting the server....
>
> Not easy, but I could not find any simpler model up to now..
>
> Stephane

You get my wrong : In what I described, jackd never runnings without
JACK running too. When Jack is running it loads the dbus deamon but the
DBus deamon cannot be running while jack is not. a -C dbus command line
does not exist.
When jack need to start (normal autostart/user command line start/...),
jackd is set up, JACK is running and it loads DBus/other control *only*
plugins. There is no always running DBus deamond listenning for
autostarting request....


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

[Stéphane Letz]

>>
>>
>> Not working because the "jackd" process may run without having the
>> JACK server running.... For example if you use "jack_control status"
>> then you see "jackd -C dbus" process, but  JACK server is still not
>> running. Then if a client does autostart the server, it does not see
>> any running JACK, then would do fork+exec and this would start a new
>> "jackd"....
>>
>> If the client call the autostart code that is available in the
>> installed "jack_control_dbus" control plugin, then it works because  
>> it
>> uses the DBus way of starting the server....
>>
>> Not easy, but I could not find any simpler model up to now..
>>
>> Stephane
>
> You get my wrong : In what I described, jackd never runnings without
> JACK running too. When Jack is running it loads the dbus deamon but  
> the
> DBus deamon cannot be running while jack is not. a -C dbus command  
> line
> does not exist.
> When jack need to start (normal autostart/user command line  
> start/...),
> jackd is set up, JACK is running and it loads DBus/other control  
> *only*
> plugins. There is no always running DBus deamond listenning for
> autostarting request....
>
>

The point is that jackd process with DBUS control plugin loaded (-C or  
always loaded) does not change the fact that client autostart feature  
does not work if the "Dbus way" to actually start the JACK server  
(inside "jackd" process) is not used.

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

[Tinram]

Le mercredi 01 juillet 2009 à 16:06 +0200, Stéphane Letz a écrit :

> >>
> >>
> >> Not working because the "jackd" process may run without having the
> >> JACK server running.... For example if you use "jack_control status"
> >> then you see "jackd -C dbus" process, but  JACK server is still not
> >> running. Then if a client does autostart the server, it does not see
> >> any running JACK, then would do fork+exec and this would start a new
> >> "jackd"....
> >>
> >> If the client call the autostart code that is available in the
> >> installed "jack_control_dbus" control plugin, then it works because  
> >> it
> >> uses the DBus way of starting the server....
> >>
> >> Not easy, but I could not find any simpler model up to now..
> >>
> >> Stephane
> >
> > You get my wrong : In what I described, jackd never runnings without
> > JACK running too. When Jack is running it loads the dbus deamon but  
> > the
> > DBus deamon cannot be running while jack is not. a -C dbus command  
> > line
> > does not exist.
> > When jack need to start (normal autostart/user command line  
> > start/...),
> > jackd is set up, JACK is running and it loads DBus/other control  
> > *only*
> > plugins. There is no always running DBus deamond listenning for
> > autostarting request....
> >
> >
>
>
> The point is that jackd process with DBUS control plugin loaded (-C or  
> always loaded) does not change the fact that client autostart feature  
> does not work if the "Dbus way" to actually start the JACK server  
> (inside "jackd" process) is not used.
>
> Stephane
>

Okay, libjack currently provide an autostart feature witch does not use
dbus, right ??
Imagine now a dbus plugins witch does not provide an autostart feature
at all, it's just a "binding" of the control API for dbus.
Control client can use this dbus interface for easier communication with
jack when jack is running,  but in order to start jack they use fork
+exec.
With a good config system has the one you proposed, your control client
in linked againt a "libjackconfig.h", manage configuration with this
API, start jack using fork+exec and a feature form taking care of the
config it has just manage and then, connect to the dbus interface and
deals with it.

That what Rythmbox, for exmaple, is doing. When it starts, it registers
a dbus object to control him, but when you kill him, his object is
erased, but of course you cannot start him trought dbus...


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

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

> - 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.

These signals already exist, they are in the control interface of the
dbus object.

> - 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)

If there is more than one plugin that has autostart feature, which one
will be used?

>>> 1. jackdbus uses different settings storage. Because guardians like
>>> the
>>> way it works for them, they are not fascinated about this. Rebels
>>> however clearly see that jackdrc format was a mistake. It is not
>>> settings format but a shell script (and some guardians use it like
>>> shell script). Moreover jackdrc format is not hierarchical. It does
>>> not
>>> allow multiconfigs. OTOH having JACK settings in two places is BAD.
>>> If
>>> one has mixed jackd+jackdbus system, both will be used. Simple
>>> convert
>>> during a transistion is not fixing the problem because both jackd and
>>> jackdbus are installed on the system.
>>
>> Now it is even worse. I get wrong settings used even when they are
>> right
>> in both places. May be this is just a little bug somewhere though.
>
> 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)

I dont see how these changes are going to fix the wrong settings being
used. I'll test later today or in next days.

> 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.

If you remove it from JACK code base it will be much easier for ladi
project to use the trunk jackdbus code that is simpler and periodically
merge only core JACK server changesets. As it is now, jackdbus depends
on only public headers too. So this changeset is cleary not making
me (as one of rebels) happy. What would make me happy is fixing the
issues that I have with current codebase. At least one of them, please?

> 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.

what is being mixed and why dbus main loop needs customization?

> - 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 already shared my long term goals about multiconfig stuff. This thing
can only make short term transition period somewhat better. But given
the anti-jackdbus FUD that has been spread, near future transition has
been probably shut down anyway.

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

My understanding, confirmed by your mail is that it is not solving even
one of the issues i've mentioned. If jackdbus stays as part of jack
codebase I can live with controlplugin stuff as log as it does not break
jackdbus workflow and usecases. If it does not I dont see why I should
cooperate and contribute to common understanding on something that gives
no value to LADI project.

If you have a goal for cooperation with me, ignoring the problems I have
and adopting the "remove dbus" POV is clearly not the way.

And to be honest it is funny how packaging error can result in such
switch upstream. Of course, it is your right as jack2 maintainer to do
whethever you want with jack2.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Nedko Arnaudov]

Martin Blanchard <tinram@...> writes:

> Okay, libjack currently provide an autostart feature witch does not use
> dbus, right ??

Currently it provides both. If dbus is choosen as prefered behaviour at
configure stage, the dbus autostarting is used. In jack1 (jack1dbus) if
that fails there is fallback to jackd launching but IIRC fallback is not
implemented in jack2.

> That what Rythmbox, for exmaple, is doing. When it starts, it registers
> a dbus object to control him, but when you kill him, his object is
> erased, but of course you cannot start him trought dbus...

Autolaunching is optional dbus feature. And it is used to achieve LADI
goals and thus is part of jackdbus.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Stéphane Letz]

Le 1 juil. 09 à 16:26, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>> - 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.
>
> These signals already exist, they are in the control interface of the
> dbus object.
>
>> - 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)
>
> If there is more than one plugin that has autostart feature, which one
> will be used?

This is the weakness for sure. But there is no real point of having  
several control plugins at the same time with the autostart feature.  
But I agree this is something to still think about.

>>
>> 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)
>
> I dont see how these changes are going to fix the wrong settings being
> used. I'll test later today or in next days.

OK thanks.

>
>> 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.
>
> If you remove it from JACK code base it will be much easier for ladi
> project to use the trunk jackdbus code that is simpler and  
> periodically
> merge only core JACK server changesets. As it is now, jackdbus depends
> on only public headers too. So this changeset is cleary not making
> me (as one of rebels) happy. What would make me happy is fixing the
> issues that I have with current codebase. At least one of them,  
> please?

I agree that "jackdbus" only depends on public headers. This is not  
the most important point. This whole control plugin idea tries to  
allow DBus based control in a less invasive manner : that is not  
requiring conditionnal compilation and not having 2 differents  
"incarnation" of the jack server. That is no ""jackd" and "jackdbus"  
but a unique "jackd" with possibly loaded control plugins.

I hope you grasp this important point yes?

>
>> 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.
>
> what is being mixed and why dbus main loop needs customization?

Because mixing DBus calls from 2 threads does not work correctly. And  
the DBus control plugin has to reorganize the previous "jackdbud.c"  
code in different manner. The  control plugin has to start a thread to  
deal with DBus requests and this thread runs along the main thread  
that will call other DBus code (like jackctl_plugin_backend_start/
jackctl_plugin_backend_stop..)

>
>> - 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 already shared my long term goals about multiconfig stuff. This  
> thing
> can only make short term transition period somewhat better. But given
> the anti-jackdbus FUD that has been spread, near future transition has
> been probably shut down anyway.
>
>> I think we would first try to get a common understanding of the
>> proposed control plugin scheme before moving on.
>
> My understanding, confirmed by your mail is that it is not solving  
> even
> one of the issues i've mentioned. If jackdbus stays as part of jack
> codebase I can live with controlplugin stuff as log as it does not  
> break
> jackdbus workflow and usecases. If it does not I dont see why I should
> cooperate and contribute to common understanding on something that  
> gives
> no value to LADI project.

But you obviously understand that the *whole point* of this control  
plugin approach is to avoid having to keep "jackdbus" alongside  
"jackd" right? Having control plugin *and* keeping "jackdbus" exe  
would just be stupid.

>
> If you have a goal for cooperation with me, ignoring the problems I  
> have
> and adopting the "remove dbus" POV is clearly not the way.

Hum.. you also obviously understand that the point is *not* to remove  
DBus control, but to implement it in a less invasive manner.  And the  
"standard jack" package + "Jack DBus control" package is a concrete  
proposal in this direction.

And I'm not ignoring problems, I try to solve them one by one, and  
frankly this DBus stuff is on top of my list right now.
>
> And to be honest it is funny how packaging error can result in such
> switch upstream. Of course, it is your right as jack2 maintainer to do
> whethever you want with jack2.
>

Bah, I suggest we stay on technical considerations only for now.

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

[Stéphane Letz]

>>
>>
>
> Okay, libjack currently provide an autostart feature witch does not  
> use
> dbus, right ??
> Imagine now a dbus plugins witch does not provide an autostart feature
> at all, it's just a "binding" of the control API for dbus.
> Control client can use this dbus interface for easier communication  
> with
> jack when jack is running,  but in order to start jack they use fork
> +exec.
> With a good config system has the one you proposed, your control  
> client
> in linked againt a "libjackconfig.h", manage configuration with this
> API, start jack using fork+exec and a feature form taking care of the
> config it has just manage and then, connect to the dbus interface and
> deals with it.

Sorry you still don't get the point. If the "jackd" processs runs but  
the JACK server inside "jackd" does not run (which can happen now)  
then the "autostarting" client using  fork+exec would just start  
another "jackd" proces, which we don't want of course.

Thus the "autostarting" client *has to* start jack server using DBus  
method in this case.

>
> That what Rythmbox, for exmaple, is doing. When it starts, it  
> registers
> a dbus object to control him, but when you kill him, his object is
> erased, but of course you cannot start him trought dbus...
>
>


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

[Tinram]

Le mercredi 01 juillet 2009 à 17:10 +0200, Stéphane Letz a écrit :
> Sorry you still don't get the point. If the "jackd" processs runs
> but  
> the JACK server inside "jackd" does not run (which can happen now)  
> then the "autostarting" client using  fork+exec would just start  
> another "jackd" proces, which we don't want of course.
>
> Thus the "autostarting" client *has to* start jack server using DBus  
> method in this case.

Yes, I know that, but it only hapenned if the current dbus plugin is
loaded, no ??

Anyway stop wasting your time with me, my app will just follow jack2
evolution and thats all.

Just to know, is you're idea of shared configuration going to be
followed or not ??


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

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

> I agree that "jackdbus" only depends on public headers. This is not
> the most important point. This whole control plugin idea tries to
> allow DBus based control in a less invasive manner : that is not
> requiring conditionnal compilation and not having 2 differents
> "incarnation" of the jack server. That is no ""jackd" and "jackdbus"
> but a unique "jackd" with possibly loaded control plugins.
>
> I hope you grasp this important point yes?

I dont see how dbus is less invasive. OTOH you get jackd executable
process that has different semantics depending on plugin being used. So
human or qjackctl see jackd in (short) process list and gets impression
that jack server is running. But it does not.

>>> - DBus calls cannot be mixed, the
>>> "dbus_connection_read_write_dispatch" has to be replace with a
>>> rewritten DBus main loop.
>>
>> what is being mixed and why dbus main loop needs customization?
>
> Because mixing DBus calls from 2 threads does not work correctly.

Why it does not work correctly?

>>> I think we would first try to get a common understanding of the
>>> proposed control plugin scheme before moving on.
>>
>> My understanding, confirmed by your mail is that it is not solving
>> even
>> one of the issues i've mentioned. If jackdbus stays as part of jack
>> codebase I can live with controlplugin stuff as log as it does not
>> break
>> jackdbus workflow and usecases. If it does not I dont see why I should
>> cooperate and contribute to common understanding on something that
>> gives
>> no value to LADI project.
>
>
> But you obviously understand that the *whole point* of this control
> plugin approach is to avoid having to keep "jackdbus" alongside
> "jackd" right? Having control plugin *and* keeping "jackdbus" exe
> would just be stupid.

Yes, I understand that you want to merge jackdbus stuff into jackd
through kind of plugin. Plugin type that is expected to have only one
incarnation installed. What I dont understand is what problem this
solves. If you consider it as a mean to remove jackdbus from trunk and
to allow jackdbus to be developed out of the tree, there is no need for
controlplugin because jackdbus can use libjackserver.so and control.h.

>> If you have a goal for cooperation with me, ignoring the problems I
>> have
>> and adopting the "remove dbus" POV is clearly not the way.
>
> Hum.. you also obviously understand that the point is *not* to remove
> DBus control, but to implement it in a less invasive manner.  And the
> "standard jack" package + "Jack DBus control" package is a concrete
> proposal in this direction.

I dont understand it like this. In your previous mail you stated it
clearly as a goal (or possibility that will happen). Or at least this is
how I parsed it. If dbus code is not shipped in the jack tarball, from
my point of view it is same as removing jackdbus from the codebase. I
can maintain such jackdbus patckage out of the tree with a git branch or
with use of the public control API. However I wont call this
cooperation. What I see as cooperation when different parties understand
problems of others and try to not confront them. In better variant,
different parties fix other ppls problems just to achieve friendly
environment.

As example I can provide my involvement in jack2 development. I've
donated lot of my personal time for implementing control API stuff that
allows cooperation and code reuse instead of branching. I contributed
waf build scripts in order to make everyone's life easier. I contributed
bugreports and wiki pages to JACK Trac. It was easier for me to just
maintain a branch and sync it with trunk. Control API is not my idea, I
accepted it and contributed to it in order to improve cooperation. And I
even got report that I cheated someone by hiding the real price for the
cooperation on control API and jackdbus.

> And I'm not ignoring problems, I try to solve them one by one, and
> frankly this DBus stuff is on top of my list right now.

From my point of view I see that not even single one of problems i've
mentioned is addressed. Instead I see refactoring that from my point of
view looks like complicating the jack architecture without single
gain. Even more, what I see is problems being introduced. Introducing
bugs when doing refactoring is not something suprising. They can and
probably will be fixed soon or later. What I dont see is what problem it
solves. You say implement jackdbus in "less invasive manner". But we
both agree (right?) that mixed jackd/jackdbus systems are bad for
users. And instead of simplifying the setup we are adding complexity and
making jackdbus unusable. So if someone gets courage to try it despite
the recent antidbus FUD it will be punished by added complexity and
introduced bugs. And IMHO the user will gain NOTHING as reward for
controlplugin stuff. Maybe I miss something, so please tell me what
benefit has the user from the controlplugin refactoring?

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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