« Return to Thread: Server control plug-ins proposal

Re: Server control plug-ins proposal

by Stéphane Letz :: Rate this Message:

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

« Return to Thread: Server control plug-ins proposal