DBus server control : description of 2 proposals

[Stéphane Letz]

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

[John Swenson]

Thanks Stéphane for the synopsis, its been hard to follow exactly what
has been proposed.

I slightly prefer proposal 2, using the same name with different
functionality controlled by options seems better to me than separate names.

I do have some reservations about plugins in general:

1) Version control. Will the plugin need to be recompiled when the
server is recompiled? If yes, some form of strong versioning is
essential to make sure the correct version of the plugin is used. If the
same plugin can be used with multiple server instantiations, when do you
have to have a new one?

With the server and plugin being in separate packages I would not rely
on the package systems to guarantee version match. The server should do
whatever is necessary to validate the plugin.

2) How to find the plugin. Will the plugin have to live in a specific
location (such as in the same directory as the server) or is a search
path necessary. If using a search path is it a new path that has to be
setup somehow, or will it "borrow" an existing search path?

John S.


Stéphane Letz wrote:

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

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

[Paul Davis]

On Thu, Jul 2, 2009 at 3:16 PM, John Swenson<johnswenson1@...> wrote:

> 1) Version control. Will the plugin need to be recompiled when the server is
> recompiled? If yes, some form of strong versioning is essential to make sure
> the correct version of the plugin is used. If the same plugin can be used
> with multiple server instantiations, when do you have to have a new one?

they communicate using an API with opaque data structures. only if the
API is changed would they need recompiling. and anyway, these
"plugins" (there would likely be 1-3 of them) would really be
considered part of JACK - packagers might bundle them separately but
they would be built from the same source release and would depend on
each other.

> 2) How to find the plugin. Will the plugin have to live in a specific
> location (such as in the same directory as the server) or is a search path
> necessary. If using a search path is it a new path that has to be setup
> somehow, or will it "borrow" an existing search path?

we have to do this for backends ("drivers") now - it works, and an
almost identical system would happen for control plugins. backends
live in a known directory ($libdir/jack) and there is no search path
involved.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fernando Lopez-Lezcano]

On Thu, 2009-07-02 at 16:20 -0400, Paul Davis wrote:

> On Thu, Jul 2, 2009 at 3:16 PM, John Swenson<johnswenson1@...> wrote:
>
> > 1) Version control. Will the plugin need to be recompiled when the server is
> > recompiled? If yes, some form of strong versioning is essential to make sure
> > the correct version of the plugin is used. If the same plugin can be used
> > with multiple server instantiations, when do you have to have a new one?
>
> they communicate using an API with opaque data structures. only if the
> API is changed would they need recompiling. and anyway, these
> "plugins" (there would likely be 1-3 of them) would really be
> considered part of JACK - packagers might bundle them separately but
> they would be built from the same source release and would depend on
> each other.

Just in the same way that in a properly packaged distribution installed
development packages have to match the original package (and yes, both
are compiled at the same time from the same source).

-- Fernando


> > 2) How to find the plugin. Will the plugin have to live in a specific
> > location (such as in the same directory as the server) or is a search path
> > necessary. If using a search path is it a new path that has to be setup
> > somehow, or will it "borrow" an existing search path?
>
> we have to do this for backends ("drivers") now - it works, and an
> almost identical system would happen for control plugins. backends
> live in a known directory ($libdir/jack) and there is no search path
> involved.


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

[Fernando Lopez-Lezcano]

On Thu, 2009-07-02 at 18:40 +0200, Stéphane Letz wrote:
> 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.

No, thanks thanks thanks to you for the summary!...

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

> 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

Good.

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

Very good.

This matches my personal (as a packager) vision. If you install this
additional package you have the dbus control capabilities, if you
uninstall it you lose them (no harm done). Very easy. I suppose that if
you don't have it installed and the plugin is called a proper message
would be printed saying that the plugin is not available.

This enables a transition to be made easily, back and forth.

It is not so simple in the first proposal as there are _two_ mutually
exclusive packages that implement the basic functionality of jack. You
install one or the other initially and that's easy. But if you want to
_switch_ from one to the other (ie: add or remove functionality), then
that is not straightforward.

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

>From the packager point of view I strongly prefer '2)' for the reasons
stated above.

'2)' also seems like a cleaner approach, but I'm still trying to find
time to read the whole thread, sorry... :-(

-- Fernando


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

[Nedko Arnaudov]

Stéphane, thanks for your summary.

> Proposal 1 (Nedko):

Correct

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

I still dont see how "jackd -C dbus" is better than jackdbus. Both
present persistent endpoint and former is even worse because it pushes
new infrastructure semantics into jackd thus causing more confusion.

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

I don't see how this is the legacy way. It presents persistent endpoint
semantics, right?

IMHO whether dbus is used or not is not the definition of legacy
way. The definition is whether it follows the legacy semantics. Legacy
semantics mean that if you have jackd process running then the server is
started. (this paragraph is not an argument against 4) above but
clarification for readers of thsi thread).

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

Indeed. Moreover, the issues that arise from "classic" plugin (default?)
and "dbus" plugin both installed are same as with my proposal. Am I
right?

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

This is in no way different from
http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

In both cases you have dbus stuff in one separate package. Reasons
behind "jackd" and "jackdbus/jackd_control_dbus.so" packages being or
being not installable simultaneously, are same for my and your
proposal.

All my above comments assume that dbus control plugin implements same
semantics as jackdbus. In particular that semantics of control and
configure interfaces are not changed.

ATM, probably because of bugs, dbus control plugin is not getting proper
setings and is not writing messages to the log file. It may be an
implementation bug, but it can be also a design issue with control
plugins that does not allow it.

D-Bus is just a mean to implement features that are needed for LADI
stuff. D-Bus is not a goal by itself. If your implementation does not
provide the features that my implementation provides, it is not
acceptable from technical point of view. Major features in jackdbus
(with comments inlined):

 * Broadcast about jack server start/stop and shared control over jack
   server.

Both implementations seem to provide this through D-Bus.

 * Simplified single thread model for control and monitor
   applications. Various D-Bus language bindings make it trivial to
   write control and monitor applications using scripting languages like
   Python, Ruby, Perl, etc..

Both implementations seem to provide this through D-Bus.

 * JACK has log file that is available for inspection even when
   autoactivation happens because of first JACK application is launched.

Not available/working with your controlplugin implementation.

 * There is real configuration file used to persist settings that can be
   manipulated through configuration interface of JACK D-Bus object.

Not available/working with your controlplugin implementation.

 * Improved graph inspection and control mechanism. JACK graph is
   versioned. Connections, ports and clients have unique (monotonically
   increasing) numeric IDs.

Both implementations seem to provide this through D-Bus.

 * High level abstraction of JACK settings. Allows applications that can
   configure JACK to expose parameters that were not known at compile
   (or tarball release) time. Recent real world examples are the JACK
   MIDI driver parameters and support for FFADO driver in
   QJackCtl. Upgrading of JACK requires upgrade of QJackCtl in order to
   make new settings available in the GUI.

Both implementations seem to provide this through D-Bus.

I'm pretty sure that log file not working in controlplugin branch is
implementation bug. I'm not sure about the configure interface and
settings file though. "jackd -C dbus -R -d alsa -p 512" suggests that
there may be design issue with how settings are handled.

Also we need to clarify whether controlplugin approach fixes the issues
caused by bad packaging. I tend to think it does not (see my comments
above).

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Stéphane Letz]

Some more remarks about the global issue:

- as Patrick said, the JACK DBus package is probably to "win" in the  
near future. Why? because it (also) practically solves the issue with  
PulseAudio interaction (something new compared to what was the reason  
of this whole JACK DBus discussion at the first place) but we have to  
keep that in mind. Thus if we go for the Nedko proposal with the  
"jackdbus" incarnation of JACK server, then is does mean that "jackd"  
incarnation of JAKC server will (practically) be dropped. It does mean  
also that Qjacktl cannot be reliably be used anymore in this new  
scheme, (only if Rui accepts to DBusify it..). People that absolutely  
want to keep the "old" way (that is "jackd" incarnation + Qjackctl..;)  
will have to hope the packagers keeps preparing the "legacy"  
package... It does also mean ./~jackdrc will be dropped and the XML  
file model will stay, if we not go for a " JACK has to keep a  
centralized view of it's state" AKA "libconfig" idea or equivalent.

- concerning code source, since we are able to cleanly separate the  
DBus controller from the main JACK2 tree (using public headers and  
linking to libjackserver.so) both solutions are somewhat equivalent in  
this regard.

- Fons propropal (AKA the 3rd one ((-: ) still does not suggest  
anything concerning "autostarts" feature. Again : "How does the  
application knows that it has to talk to B? In other words assuming  
several B kind of control applications are installed, how to define  
the one the "autolaunch" scheme is supposed to use?"

- if we go for the Nedko proposal, than I consider that as a really  
MAJOR shift in the history of JACK. Again I'm quite sure the "jackd"  
incarnation will quite soon disappear  on Linux. It will stay on other  
platforms (OSX, Windows, Solaris..). I still don't think this is a  
good idea at all...

- the best I can do on my side is to work on the controlplugin  
proposal since it still contains several issues, so that the  
comparison can be done with 2 workable solutions.

Stephane

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

[Nedko Arnaudov]

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

> - if we go for the Nedko proposal, than I consider that as a really
> MAJOR shift in the history of JACK. Again I'm quite sure the "jackd"
> incarnation will quite soon disappear  on Linux. It will stay on other
> platforms (OSX, Windows, Solaris..). I still don't think this is a
> good idea at all...

I think there will be always minimalistic linux distros that dont have
dbus, kits and other things that bloat the system is some use
cases. Given that AFAIK all major distros are not sutiable for jack
audio by default and that current trend is to provide "derivates" like
Planet CCRMA, Ubuntu Studio, 64 Studio, proaudio overlay, etc., wide
adoption of mixed jack+desktop technologies wont happen that fast (or
wont happen at all). The other trend is to make major distros suitable
for linux audio out of the box. If this happens then dbus interface to
jack will probably be adopted too. But I dont think it will happen that
soon.

OTOH, I find it silly to try to force policies to distros. Distros do
whethever they want anyway. They patch source trees to fit their
policies, they apply patches that suit their needs, etc. Upstreams can
advise packagers but cant force them. yes, they can cause them pain but
don't expect thankfulness as response. So I think it is best to keep the
dbus option disabled by default. If and when there is enough distros
that adopt jack+dbus, we can change the default. Pushing prodesktop or
antidesktop policies to all distros is silly and will probably have no
effect at all. Lets give the distros a choice and give them advices for
their needs while not pushing our personal POV to them.

--
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 3 juil. 09 à 05:19, Nedko Arnaudov a écrit :

>
> Stéphane, thanks for your summary.
>
>> Proposal 1 (Nedko):
>
> Correct
>
>> 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.
>
> I still dont see how "jackd -C dbus" is better than jackdbus. Both
> present persistent endpoint and former is even worse because it pushes
> new infrastructure semantics into jackd thus causing more confusion.
>
>> 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.
>
> I don't see how this is the legacy way. It presents persistent  
> endpoint
> semantics, right?
>
> IMHO whether dbus is used or not is not the definition of legacy
> way. The definition is whether it follows the legacy semantics. Legacy
> semantics mean that if you have jackd process running then the  
> server is
> started. (this paragraph is not an argument against 4) above but
> clarification for readers of thsi thread).

jackd -C dbus : does start that the process but does not start the  
JACK server

jackd -C dbus  -R -d alsa : does start that the process and use the  
parameters given on command line (this taking over the one kept in  
DBus XML config)

Yes it does change the semantic a bit, but maybe this is the price to  
pay to keep the "jackd" incarnation.

>
>> 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.
>
> Indeed. Moreover, the issues that arise from "classic" plugin  
> (default?)
> and "dbus" plugin both installed are same as with my proposal. Am I
> right?

This is not "classic" plugin indeed, if no control plugin with  
"autostart" feature is found, then fork-exec model is used.

>
>
>> 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.
>
> This is in no way different from
> http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
>
> In both cases you have dbus stuff in one separate package. Reasons
> behind "jackd" and "jackdbus/jackd_control_dbus.so" packages being or
> being not installable simultaneously, are same for my and your
> proposal.

Well the biggest difference I see is that the "old" model IS the  
standard package and is here to stay. So guardians can keep the old  
way (even if they may have to deactivate PuleAudio to get entire  
control)

The DBus package would then add DBus controler on top, assuming people  
will then use DBus based control tools (jack_control and others)

>
> All my above comments assume that dbus control plugin implements same
> semantics as jackdbus. In particular that semantics of control and
> configure interfaces are not changed.
>
> ATM, probably because of bugs, dbus control plugin is not getting  
> proper
> setings and is not writing messages to the log file. It may be an
> implementation bug, but it can be also a design issue with control
> plugins that does not allow it.
>
> D-Bus is just a mean to implement features that are needed for LADI
> stuff. D-Bus is not a goal by itself. If your implementation does not
> provide the features that my implementation provides, it is not
> acceptable from technical point of view. Major features in jackdbus
> (with comments inlined):
>
> * Broadcast about jack server start/stop and shared control over jack
>   server.
>
> Both implementations seem to provide this through D-Bus.
>
> * Simplified single thread model for control and monitor
>   applications. Various D-Bus language bindings make it trivial to
>   write control and monitor applications using scripting languages  
> like
>   Python, Ruby, Perl, etc..
>
> Both implementations seem to provide this through D-Bus.
>
> * JACK has log file that is available for inspection even when
>   autoactivation happens because of first JACK application is  
> launched.
>
> Not available/working with your controlplugin implementation.
>
> * There is real configuration file used to persist settings that can  
> be
>   manipulated through configuration interface of JACK D-Bus object.
>
> Not available/working with your controlplugin implementation.
>
> * Improved graph inspection and control mechanism. JACK graph is
>   versioned. Connections, ports and clients have unique (monotonically
>   increasing) numeric IDs.
>
> Both implementations seem to provide this through D-Bus.
>
> * High level abstraction of JACK settings. Allows applications that  
> can
>   configure JACK to expose parameters that were not known at compile
>   (or tarball release) time. Recent real world examples are the JACK
>   MIDI driver parameters and support for FFADO driver in
>   QJackCtl. Upgrading of JACK requires upgrade of QJackCtl in order to
>   make new settings available in the GUI.
>
> Both implementations seem to provide this through D-Bus.
>
> I'm pretty sure that log file not working in controlplugin branch is
> implementation bug. I'm not sure about the configure interface and
> settings file though. "jackd -C dbus -R -d alsa -p 512" suggests that
> there may be design issue with how settings are handled.
>
> Also we need to clarify whether controlplugin approach fixes the  
> issues
> caused by bad packaging. I tend to think it does not (see my comments
> above).
>

Looking at that.

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

[Nedko Arnaudov]

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

> jackd -C dbus : does start that the process but does not start the
> JACK server
>
> jackd -C dbus  -R -d alsa : does start that the process and use the
> parameters given on command line (this taking over the one kept in
> DBus XML config)
>
> Yes it does change the semantic a bit, but maybe this is the price to
> pay to keep the "jackd" incarnation.

So what happens when "jackd -C dbus  -R -d alsa" recevices server stop request
through dbus? And does it report correct settings that are supplied on
commandlined through the configure interface. And how it stores settings
after that?

>>> 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.
>>
>> Indeed. Moreover, the issues that arise from "classic" plugin
>> (default?)
>> and "dbus" plugin both installed are same as with my proposal. Am I
>> right?
>
> This is not "classic" plugin indeed, if no control plugin with
> "autostart" feature is found, then fork-exec model is used.

But issues with mixed system are still same, right?

>>> 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.
>>
>> This is in no way different from
>> http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
>>
>> In both cases you have dbus stuff in one separate package. Reasons
>> behind "jackd" and "jackdbus/jackd_control_dbus.so" packages being or
>> being not installable simultaneously, are same for my and your
>> proposal.
>
> Well the biggest difference I see is that the "old" model IS the
> standard package and is here to stay. So guardians can keep the old
> way (even if they may have to deactivate PuleAudio to get entire
> control)
>
> The DBus package would then add DBus controler on top, assuming people
> will then use DBus based control tools (jack_control and others)

Dbus must be separate package even with my proposal. And classic jackd
must be in "standard" package. As is documented long time ago in that
wiki page.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Rui Nuno Capela]

On Fri, July 3, 2009 08:48, Stéphane Letz wrote:

> Some more remarks about the global issue:
>
>
> - as Patrick said, the JACK DBus package is probably to "win" in the
> near future. Why? because it (also) practically solves the issue with
> PulseAudio interaction (something new compared to what was the reason
> of this whole JACK DBus discussion at the first place) but we have to keep
> that in mind. Thus if we go for the Nedko proposal with the "jackdbus"
> incarnation of JACK server, then is does mean that "jackd" incarnation of
> JAKC server will (practically) be dropped. It does mean
> also that Qjacktl cannot be reliably be used anymore in this new scheme,
> (only if Rui accepts to DBusify it..).

yep i could do it... problem is that it will most certainly fail any
time-to-market deadline, i repeat *any* -- uber-procrastinator dixit :)

ok, any dbus-ified version of qjackctl is better off being a complete
brand new application. a brand new project that is. unfortunately, i'm not
seeing that happen anytime soon under my radar, sorry to tell.

however, it is my understanding that the possible hole left from a lack of
qjackctl on Nedko's jackdbus encarnation (1st prop) is filled up with the
ladi tools or whatever they are.

uber-procrastinator says: the 2nd prop is the one which seems the better
way to go ;)

it is important, at least from my pov, that starting the jackd server in
the so called legacy way of settings (eg. jackd -R -d alsa -dhw:1 -p128
-n3 ...) is to be kept always honored, independent of what control/config
api implementation. with time it may become deprecated and ultimately
convicted. time and genetics will tell the fate of jackd usage :)


> People that absolutely want to keep the "old" way (that is "jackd"
> incarnation + Qjackctl..;) will have to hope the packagers keeps
> preparing the "legacy" package... It does also mean ./~jackdrc will be
> dropped and the XML file model will stay, if we not go for a " JACK has
> to keep a centralized view of it's state" AKA "libconfig" idea or
> equivalent.
>

all that shall happen, eventually, not abruptly. i guess.

cheers
--
rncbc aka Rui Nuno Capela
rncbc@...

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

[Nedko Arnaudov]

"Rui Nuno Capela" <rncbc@...> writes:

> it is important, at least from my pov, that starting the jackd server in
> the so called legacy way of settings (eg. jackd -R -d alsa -dhw:1 -p128
> -n3 ...) is to be kept always honored, independent of what control/config
> api implementation. with time it may become deprecated and ultimately
> convicted. time and genetics will tell the fate of jackd usage :)

starting jackd is valid, preserving the semantics and honored with both
proposals.

--
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 3 juil. 09 à 10:31, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>> jackd -C dbus : does start that the process but does not start the
>> JACK server
>>
>> jackd -C dbus  -R -d alsa : does start that the process and use the
>> parameters given on command line (this taking over the one kept in
>> DBus XML config)
>>
>> Yes it does change the semantic a bit, but maybe this is the price to
>> pay to keep the "jackd" incarnation.
>
> So what happens when "jackd -C dbus  -R -d alsa" recevices server  
> stop request
> through dbus? And does it report correct settings that are supplied on
> commandlined through the configure interface. And how it stores  
> settings
> after that?

Parameters on command line "take over" the one kept in XML file during  
the life of jackd process. If started/stopped then the command line  
ones are still used. They are not saved in XML file. Thus next use  
using "jack_control" would take XML ones.

Please test latest commit c1d9bcea440d432b5acff3d3d7ee00ad02b3c0b5. It  
fixes log issues and setting management.

>
>>>> 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.
>>>
>>> Indeed. Moreover, the issues that arise from "classic" plugin
>>> (default?)
>>> and "dbus" plugin both installed are same as with my proposal. Am I
>>> right?
>>
>> This is not "classic" plugin indeed, if no control plugin with
>> "autostart" feature is found, then fork-exec model is used.
>
> But issues with mixed system are still same, right?

As soon as DBus control plugin would be installed on top of "standard"  
JACK2, then "autostart"  would be DBus one in any case.

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

[Fernando Lopez-Lezcano]

On Fri, 2009-07-03 at 06:19 +0300, Nedko Arnaudov wrote:

> Stéphane, thanks for your summary.
> > 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.
>
> This is in no way different from
> http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
>
> In both cases you have dbus stuff in one separate package. Reasons
> behind "jackd" and "jackdbus/jackd_control_dbus.so" packages being or
> being not installable simultaneously, are same for my and your
> proposal.

The difference is a matter of how dependencies are handled, complexity
of the solution and additional packaging conditions regarding mutual
exclusiveness of packages. The relevant part is:

- "jack server frontend" - virtual package ("jackd" and "jackdbus")
- "jack server (library)"
- "jackd" - package containing jackd binary.
- "jackdbus" - package containing jackdbus binary and jack_control

Unless I misunderstand there are _two_ mutually incompatible packages -
jackd and jackdbus - (ie: only one of them may be installed at a given
time), with different names and a virtual package that provides the
needed global dependency for the rest of the packages (so that both
appear to be the "same" with regards to dependencies).

Proposal 'b)' has _one_ package that provides basic functionality and is
not incompatible with anything else. It does not need virtual packages
to take care of dependencies. It has to be installed for jack to work at
all (same as now) and there is no choice to be made at that point. That,
to my packager eyes, _is_ different, and much simpler.

Adding one package adds the extra functionality. In proposal 'a)' you
need to switch packages (switch between jackd and jackdbus package).

Also, jackd and jackdbus packages provide binaries that are named
_differently_ if I understand correctly. That seems to be bad. Depending
on what choice you took the binary that starts jack is _different_. I
have not mentally followed the ramifications to the end, but it seems to
me that it is going to cause trouble at some point when/if switching
back and forth.

-- Fernando


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

[Nedko Arnaudov]

Fernando Lopez-Lezcano <nando@...> writes:

> On Fri, 2009-07-03 at 06:19 +0300, Nedko Arnaudov wrote:
>> Stéphane, thanks for your summary.
>> > 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.
>>
>> This is in no way different from
>> http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
>>
>> In both cases you have dbus stuff in one separate package. Reasons
>> behind "jackd" and "jackdbus/jackd_control_dbus.so" packages being or
>> being not installable simultaneously, are same for my and your
>> proposal.
>
> The difference is a matter of how dependencies are handled, complexity
> of the solution and additional packaging conditions regarding mutual
> exclusiveness of packages. The relevant part is:
>
> - "jack server frontend" - virtual package ("jackd" and "jackdbus")
> - "jack server (library)"
> - "jackd" - package containing jackd binary.
> - "jackdbus" - package containing jackdbus binary and jack_control
>
> Unless I misunderstand there are _two_ mutually incompatible packages -
> jackd and jackdbus - (ie: only one of them may be installed at a given
> time), with different names and a virtual package that provides the
> needed global dependency for the rest of the packages (so that both
> appear to be the "same" with regards to dependencies).
>
> Proposal 'b)' has _one_ package that provides basic functionality and is
> not incompatible with anything else. It does not need virtual packages
> to take care of dependencies. It has to be installed for jack to work at
> all (same as now) and there is no choice to be made at that point. That,
> to my packager eyes, _is_ different, and much simpler.
>
> Adding one package adds the extra functionality. In proposal 'a)' you
> need to switch packages (switch between jackd and jackdbus package).

You misunderstood indeed. The incompatibility level is same with
jackdbus and with dbus controlplugin.

> Also, jackd and jackdbus packages provide binaries that are named
> _differently_ if I understand correctly. That seems to be bad. Depending
> on what choice you took the binary that starts jack is _different_. I
> have not mentally followed the ramifications to the end, but it seems to
> me that it is going to cause trouble at some point when/if switching
> back and forth.

They are named differently, yes. jackd and jackdbus executables
expose different high level semantics. OTOH with controlplugin approach
you get new persistent endpoint semantic pushed to jackd. You may like
it but I think it is worse. Because it will be more intrusive to whom
wants to use just jackd in mixed environment. With jackdbus approach
jackd stays clean of dbus. With controlplugin, jackd could (but you cant
easily be sure) use dbus and *may* suggest that jack server is
started. Moreover, controlplugin approach so far has not shown a single
thing that makes it superior. But is has shown that controlplugin makes
codebase more complex. More complexity  means more maintance effort is
needed and it means that more bugs are likely to lurk in larger
codebase. Of course you are free to decide what you will package and of
course I'm not the one who decides what to be in the released "jack"
tarball(s). What I can decide is what is best for LADI. And I'll support
what is best for LADI.

To be honest I'm starting to think that either I'm insane or lot of
other ppl are insane. In either case I the sane thing to stop this
insanity is for me to stop contributing to this discussion. We
are doing technical discussion (as requested by Stephane) but ppl keep
telling that they want controlplugin even when they have not tried it
nor understood it. Maybe I'm geting paranoia but I start to suspect that
this is a trail of the recent anti-jackdbus flame war. Sorry but if you
keep acting like this, I'll just stop wasting my time with this
thread. It is easier for me. And it will be easier for you too, I
guess. You will remove dbus jack (or whether insane goal you have) and
I'll just keep it in my git branch. Beleive me, it is easier for me to
act like this. But I'm still trying to find compromise and I waste my
time in this discussion to repeat things that I've already said it this
very same thread. And I'm doint this because I'm sure that jackdbus out
of jack codebase will be worse for the JACK project. And I don't want
bad things to happen to JACK  because I appreciate the effort Stephane
puts on jack2.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Nedko Arnaudov]

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

> Le 3 juil. 09 à 10:31, Nedko Arnaudov a écrit :
>
>> Stéphane Letz <letz@...> writes:
>>
>>> jackd -C dbus : does start that the process but does not start the
>>> JACK server
>>>
>>> jackd -C dbus  -R -d alsa : does start that the process and use the
>>> parameters given on command line (this taking over the one kept in
>>> DBus XML config)
>>>
>>> Yes it does change the semantic a bit, but maybe this is the price to
>>> pay to keep the "jackd" incarnation.
>>
>> So what happens when "jackd -C dbus  -R -d alsa" recevices server
>> stop request
>> through dbus? And does it report correct settings that are supplied on
>> commandlined through the configure interface. And how it stores
>> settings
>> after that?
>
> Parameters on command line "take over" the one kept in XML file during
> the life of jackd process. If started/stopped then the command line
> ones are still used. They are not saved in XML file. Thus next use
> using "jack_control" would take XML ones.
>
> Please test latest commit c1d9bcea440d432b5acff3d3d7ee00ad02b3c0b5. It
> fixes log issues and setting management.

Both bugs seem to be fixed, I've picked the next revision,
4cb15b432d60afa69526c2136bcb18c160a0f8ce.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Nedko Arnaudov]

Nedko Arnaudov <nedko@...> writes:

>> Please test latest commit c1d9bcea440d432b5acff3d3d7ee00ad02b3c0b5. It
>> fixes log issues and setting management.
>
> Both bugs seem to be fixed, I've picked the next revision,
> 4cb15b432d60afa69526c2136bcb18c160a0f8ce.

I'm getting crash when I try to configure jack through dbus:

Sat Jul  4 18:39:19 2009: dbus : thread started...
Sat Jul  4 18:39:22 2009: ERROR: Segmentation Fault!
Sat Jul  4 18:39:22 2009: ERROR: info.si_signo = 11
Sat Jul  4 18:39:22 2009: ERROR: info.si_errno = 0
Sat Jul  4 18:39:22 2009: ERROR: info.si_code  = 1 (SEGV_MAPERR)
Sat Jul  4 18:39:22 2009: ERROR: info.si_addr  = 0x1
Sat Jul  4 18:39:22 2009: ERROR: reg[00]       = 0x00000033
Sat Jul  4 18:39:22 2009: ERROR: reg[01]       = 0x00000000
Sat Jul  4 18:39:22 2009: ERROR: reg[02]       = 0x0000007b
Sat Jul  4 18:39:22 2009: ERROR: reg[03]       = 0x0000007b
Sat Jul  4 18:39:22 2009: ERROR: reg[04]       = 0x00000000
Sat Jul  4 18:39:22 2009: ERROR: reg[05]       = 0x00000001
Sat Jul  4 18:39:22 2009: ERROR: reg[06]       = 0xb7ada058
Sat Jul  4 18:39:22 2009: ERROR: reg[07]       = 0xb7ada01c
Sat Jul  4 18:39:22 2009: ERROR: reg[08]       = 0xb7ebeff4
Sat Jul  4 18:39:22 2009: ERROR: reg[09]       = 0xb7ada160
Sat Jul  4 18:39:22 2009: ERROR: reg[10]       = 0x00000001
Sat Jul  4 18:39:22 2009: ERROR: reg[11]       = 0x00000001
Sat Jul  4 18:39:22 2009: ERROR: reg[12]       = 0x0000000e
Sat Jul  4 18:39:22 2009: ERROR: reg[13]       = 0x00000004
Sat Jul  4 18:39:22 2009: ERROR: reg[14]       = 0xb7c8547b
Sat Jul  4 18:39:22 2009: ERROR: reg[15]       = 0x00000073
Sat Jul  4 18:39:22 2009: ERROR: reg[16]       = 0x00010202
Sat Jul  4 18:39:22 2009: ERROR: reg[17]       = 0xb7ada01c
Sat Jul  4 18:39:22 2009: ERROR: reg[18]       = 0x0000007b
Sat Jul  4 18:39:22 2009: ERROR: Stack trace:
Sat Jul  4 18:39:22 2009: ERROR:  1: 0xb7c8547b <strlen+11> (/lib/libc.so.6)
Sat Jul  4 18:39:22 2009: ERROR:  2: 0xb7e9dcbc <(null)[phone]> (/usr/lib/libdbus-1.so.3)
Sat Jul  4 18:39:22 2009: ERROR:  3: 0xb7e9dd1a <(null)[phone]> (/usr/lib/libdbus-1.so.3)
Sat Jul  4 18:39:22 2009: ERROR:  4: 0xb7ea24dc <dbus_message_iter_append_basic+188> (/usr/lib/libdbus-1.so.3)
Sat Jul  4 18:39:22 2009: ERROR:  5: 0xb7b02c69 <(null)[phone]> (/usr/lib/jack/jack_control_dbus.so)
Sat Jul  4 18:39:22 2009: ERROR:  6: 0xb7b01119 <jack_dbus_run_method+73> (/usr/lib/jack/jack_control_dbus.so)
Sat Jul  4 18:39:22 2009: ERROR:  7: 0xb7b011ee <jack_dbus_message_handler+190> (/usr/lib/jack/jack_control_dbus.so)
Sat Jul  4 18:39:22 2009: ERROR:  8: 0xb7ea57db <(null)[phone]> (/usr/lib/libdbus-1.so.3)
Sat Jul  4 18:39:22 2009: ERROR:  9: 0xb7e97b76 <dbus_connection_dispatch+1030> (/usr/lib/libdbus-1.so.3)
Sat Jul  4 18:39:22 2009: ERROR:  10: 0xb7e97ebe <(null)[phone]> (/usr/lib/libdbus-1.so.3)
Sat Jul  4 18:39:22 2009: ERROR:  11: 0xb7b009c6 <(null)[phone]> (/usr/lib/jack/jack_control_dbus.so)
Sat Jul  4 18:39:22 2009: ERROR:  12: 0xb7e77120 <(null)[phone]> (/lib/libpthread.so.0)
Sat Jul  4 18:39:22 2009: ERROR: End of stack trace

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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