Server control plug-ins proposal

[Nedko Arnaudov]

Martin Blanchard <tinram@...> writes:

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

I personally accept it as good thing and I'll support it if it gets
push. And that push is from Paul (ardour) and Rui (qjackctl). Without
them supporting it, the idea is doomed.

--
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 à 17:50, Nedko Arnaudov a écrit :

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

Sure, this was the fact also with "jackdbus"  process.

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

Deadlock AFAICS

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

It solves the double "jackd" , "jackbus" server incarnation issue and  
it does remove the conditional compilation used in libjack code  
(precisely in JackPosixServerLaunch.cpp file) that use the DBUS mode  
for the client "autostart" feature.

At the same time it also move the DBUS based acquire/release audio  
card code (not you code this time..), that was conditionally compiled  
in ALSA backend.

The result is that all DBUS based code is now grouped and compiled  
separated from the main JACK2 tree.

It also allows to move this OSX specific code that was still in  
jackdmp.cpp file, (that you were rightly complaining about) and that  
is now compiled in a jack_control_osx plugin.

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

Which I think I try to do with the plugin proposal.  I consider much  
better and cleaner to be able to develop and compile a control plugin  
only using public headers and linking to libjackserver.so that having  
to *patch* the JAC2K source tree (which is still the case in  
particular with the  DBUS code in JackPosixServerLaunch.cpp file).

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

Yes, and I thank you for all your contributions. You did a *lot* and  
this is frankly great, again I'm not trying to remove stuff but  
suggest another implementation.

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

OK, OK, refactoring may introduce bugs, but may also cleanup things. I  
don't think it is a strong argument by itself.

dbusplugin.c code is actually 99.9 % of your jackdbus.c code + DBUS  
code that was in JackPosixServerLaunch.cpp + DBUS code that was in  
JackAlsaDriver.cpp.


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

In some sense yes, but the new model allows guardian to *just* install  
the what would be so-called "standard" JACK2. In this case no DBUS  
stuff would be installed at all. I consider this as a gain. Then DBUS  
aware users would install the new so-called DBUS control package and  
gain DBUS control, with the possible issues that may stay. But then  
those users are hopefully knowing the possible issues (like using  
Qjackctl tool along pure DBUS based control tools...)

But again how could we do better, without  1) kind of fork (like  
maintaining a DBUS patched tree) or 2) single jackd/jackdbus package  
with the all the problems that actually started this whole DBUS  
flamewar or 2) double packaging (one "jackd" based , one "jackdbus"  
based package) ?

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


I hope some of the previous arguments explain the benefits.

Stephane


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

[Nedko Arnaudov]

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

> Le 1 juil. 09 à 17:50, Nedko Arnaudov a écrit :
>
>> 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.
>
> Sure, this was the fact also with "jackdbus"  process.

No it is not. Whom checks for jackd (human, ardour or qjackctl)
will not find jackd as running.

>>>>> 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.
>
> It solves the double "jackd" , "jackbus" server incarnation issue and
> it does remove the conditional compilation used in libjack code
> (precisely in JackPosixServerLaunch.cpp file) that use the DBUS mode
> for the client "autostart" feature.

This issue is result of packaging error. I don't see why anyone will
want to use both classic jackd and jackdbus. I do/did have them
installed both but this is because I know how they (don't)
interoperate. Moreover on the packager oriented wiki page in jack track
I've clearly stated what bad things that will happen when both jackd and
jackdbus are mixed. I've made this as an attempt to help packagers to do
informed decisions and thus please their users. Unfortunately this did't
work for Fons. I tend to think that this happened because that
documentation was not being pushed enough to packagers and one of them
was not aware.

> At the same time it also move the DBUS based acquire/release audio
> card code (not you code this time..), that was conditionally compiled
> in ALSA backend.
>
> The result is that all DBUS based code is now grouped and compiled
> separated from the main JACK2 tree.

This can be achieved in with the trunk approach. In the same way. I dont
see how controlplugin refactoring is related to refactoring alsa+pa
code. The fact that you are making them both in the controlplugin branch
is making them related.

> It also allows to move this OSX specific code that was still in
> jackdmp.cpp file, (that you were rightly complaining about) and that
> is now compiled in a jack_control_osx plugin.

If you like it like this, fine. I personally dont care about operating
systems that take away the freedom. I'm not against. I just dont care
and I dont donate my time to cause that is supporting (voluntary)
enslavement. Actually I've seen once how jackd operates on Leopard. I
was not pleased at all.

BTW I wonder what will happen if/when Apple add dbus to OSX. Maybe the
"linux virtual studio" I'm creating will be operational on OSX too. Of
course the use-only-posix-and-reinvent-wheels dogma will be broken.

OTOH I have to say that OSX integration should be done through mach
ports and helper library. At least this is the impression I have about
what is native on OSX.

>>>> 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.
>
> Which I think I try to do with the plugin proposal.  I consider much
> better and cleaner to be able to develop and compile a control plugin
> only using public headers and linking to libjackserver.so that having
> to *patch* the JAC2K source tree (which is still the case in
> particular with the  DBUS code in JackPosixServerLaunch.cpp file).

Again, one can "develop and compile" jackdbus and other frontends to
jackd server through the control API that is already in trunk. As for
jack server autostart, this can be solved by launching dbus-send or some
custom utility (probably named "jackd").

>> 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.
>
> In some sense yes, but the new model allows guardian to *just* install
> the what would be so-called "standard" JACK2. In this case no DBUS
> stuff would be installed at all. I consider this as a gain. Then DBUS
> aware users would install the new so-called DBUS control package and
> gain DBUS control, with the possible issues that may stay. But then
> those users are hopefully knowing the possible issues (like using
> Qjackctl tool along pure DBUS based control tools...)
>
> But again how could we do better, without  1) kind of fork (like
> maintaining a DBUS patched tree) or 2) single jackd/jackdbus package
> with the all the problems that actually started this whole DBUS
> flamewar or 2) double packaging (one "jackd" based , one "jackdbus"
> based package) ?

Let me state it clearly. mixing jackd and jackdbus is as bad as mixing
jack1 and jack2. If someone has motivation to provide user support for
this insane environment - fine. I dont. The most bold arguments of
anti-dbus guardians were against libjack.so dynamically linking
libdbus.so. This issue can be fixed without the merge of jackd and
jackdbus and has nothing to do with it. You are solving it through
client-side (libjack.so) plugins. I think this is overkill. Because
there are much simpler solutions for this proble. Solutions that dont
require massive refactoring that introduces loadable plugins, when only
single plugin is going to be installed anyway. One of them is to execute
dbus-send program. Other one is to provide custom launcher. It can even
be called jackd. It can be solved even by puting dbus-send into
~/.jackdrc. And all of these much simpler solutions will also fix the
licensing problem that was mentioned (I still dont see how the
LGPL license is violated though).

>> 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?
>>
>
>
> I hope some of the previous arguments explain the benefits.

Unfortunately they don't. Or I dont see these things as benefits.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Nedko Arnaudov]

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

[snip]

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

No improvement with bc3ad833b6262e565483f7912a75c5f895dec6e5. I still
get no messages in the log file and wrong jack server configuration.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Stéphane Letz]

>>
>> Sure, this was the fact also with "jackdbus"  process.
>
> No it is not. Whom checks for jackd (human, ardour or qjackctl)
> will not find jackd as running.

If the user uses qjackctl in a JACK + DBUS based setup which we both  
agree is potentially problematic in any case right?

>>
>> It solves the double "jackd" , "jackbus" server incarnation issue and
>> it does remove the conditional compilation used in libjack code
>> (precisely in JackPosixServerLaunch.cpp file) that use the DBUS mode
>> for the client "autostart" feature.
>
> This issue is result of packaging error. I don't see why anyone will
> want to use both classic jackd and jackdbus. I do/did have them
> installed both but this is because I know how they (don't)
> interoperate. Moreover on the packager oriented wiki page in jack  
> track
> I've clearly stated what bad things that will happen when both  
> jackd and
> jackdbus are mixed. I've made this as an attempt to help packagers  
> to do
> informed decisions and thus please their users. Unfortunately this  
> did't
> work for Fons. I tend to think that this happened because that
> documentation was not being pushed enough to packagers and one of them
> was not aware.

So do you really suggest that 2 *complete* (that is server, libjack,  
headers,  tools..) JACK package would have to be produced? Do you  
really think this would simplify users life?

>
>> At the same time it also move the DBUS based acquire/release audio
>> card code (not you code this time..), that was conditionally compiled
>> in ALSA backend.
>>
>> The result is that all DBUS based code is now grouped and compiled
>> separated from the main JACK2 tree.
>
> This can be achieved in with the trunk approach. In the same way. I  
> dont
> see how controlplugin refactoring is related to refactoring alsa+pa
> code. The fact that you are making them both in the controlplugin  
> branch
> is making them related.

Yep. The point is use this control plugin approach as the way to  
cleanup things that can be cleanp up. And the DBUS acquire/release  
code in ALSA backend was not the most clean thing.

>
>> It also allows to move this OSX specific code that was still in
>> jackdmp.cpp file, (that you were rightly complaining about) and that
>> is now compiled in a jack_control_osx plugin.
>
> If you like it like this, fine. I personally dont care about operating
> systems that take away the freedom. I'm not against. I just dont care
> and I dont donate my time to cause that is supporting (voluntary)
> enslavement. Actually I've seen once how jackd operates on Leopard. I
> was not pleased at all.
>

  Not technical argumentation, I don't think I need to answer that.


> BTW I wonder what will happen if/when Apple add dbus to OSX. Maybe the
> "linux virtual studio" I'm creating will be operational on OSX too. Of
> course the use-only-posix-and-reinvent-wheels dogma will be broken.

If this happens , then the DBUS control plugin would potentially be  
usable on OSX also; So what is the point?

>
> OTOH I have to say that OSX integration should be done through mach
> ports and helper library. At least this is the impression I have about
> what is native on OSX.
>
>>
>> Which I think I try to do with the plugin proposal.  I consider much
>> better and cleaner to be able to develop and compile a control plugin
>> only using public headers and linking to libjackserver.so that having
>> to *patch* the JAC2K source tree (which is still the case in
>> particular with the  DBUS code in JackPosixServerLaunch.cpp file).
>
> Again, one can "develop and compile" jackdbus and other frontends to
> jackd server through the control API that is already in trunk. As for
> jack server autostart, this can be solved by launching dbus-send or  
> some
> custom utility (probably named "jackd").

This is a new proposal AFAICS : can you explain exactly how it would  
work?

>
>>> 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.
>>
>> In some sense yes, but the new model allows guardian to *just*  
>> install
>> the what would be so-called "standard" JACK2. In this case no DBUS
>> stuff would be installed at all. I consider this as a gain. Then DBUS
>> aware users would install the new so-called DBUS control package and
>> gain DBUS control, with the possible issues that may stay. But then
>> those users are hopefully knowing the possible issues (like using
>> Qjackctl tool along pure DBUS based control tools...)
>>
>> But again how could we do better, without  1) kind of fork (like
>> maintaining a DBUS patched tree) or 2) single jackd/jackdbus package
>> with the all the problems that actually started this whole DBUS
>> flamewar or 2) double packaging (one "jackd" based , one "jackdbus"
>> based package) ?
>
> Let me state it clearly. mixing jackd and jackdbus is as bad as mixing
> jack1 and jack2. If someone has motivation to provide user support for
> this insane environment - fine. I dont. The most bold arguments of
> anti-dbus guardians were against libjack.so dynamically linking
> libdbus.so. This issue can be fixed without the merge of jackd and
> jackdbus and has nothing to do with it.

Please suggest something concrete (on a git branch or something)

> You are solving it through
> client-side (libjack.so) plugins. I think this is overkill. Because
> there are much simpler solutions for this proble. Solutions that dont
> require massive refactoring that introduces loadable plugins, when  
> only
> single plugin is going to be installed anyway. One of them is to  
> execute
> dbus-send program. Other one is to provide custom launcher. It can  
> even
> be called jackd. It can be solved even by puting dbus-send into
> ~/.jackdrc. And all of these much simpler solutions will also fix the
> licensing problem that was mentioned (I still dont see how the
> LGPL license is violated though).

What about the DBUS code that would stay in ALSA backend?

>
>>> 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?
>>>
>>
>>
>> I hope some of the previous arguments explain the benefits.
>
> Unfortunately they don't. Or I dont see these things as benefits.

Stephane


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

[Nedko Arnaudov]

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

>>>
>>> Sure, this was the fact also with "jackdbus"  process.
>>
>> No it is not. Whom checks for jackd (human, ardour or qjackctl)
>> will not find jackd as running.
>
> If the user uses qjackctl in a JACK + DBUS based setup which we both
> agree is potentially problematic in any case right?

No. AFAIK qjackctl will be able to stop jackd process assuming it is the
server while it is just the persistent endpoint. OTOH my proposal solves
the problem with qjackctl and ardour. My proposal is in the
guardian/rebels mail and also contains a diagram. Diagram that got no
responses because it was pusing details that some guardians refuse to
agree to exist (too complicated, too big, etc). Just because some
diagram is not oversimplificated and pushing limited POV does not mean
it is complicated.

>>> It solves the double "jackd" , "jackbus" server incarnation issue and
>>> it does remove the conditional compilation used in libjack code
>>> (precisely in JackPosixServerLaunch.cpp file) that use the DBUS mode
>>> for the client "autostart" feature.
>>
>> This issue is result of packaging error. I don't see why anyone will
>> want to use both classic jackd and jackdbus. I do/did have them
>> installed both but this is because I know how they (don't)
>> interoperate. Moreover on the packager oriented wiki page in jack
>> track
>> I've clearly stated what bad things that will happen when both
>> jackd and
>> jackdbus are mixed. I've made this as an attempt to help packagers
>> to do
>> informed decisions and thus please their users. Unfortunately this
>> did't
>> work for Fons. I tend to think that this happened because that
>> documentation was not being pushed enough to packagers and one of them
>> was not aware.
>
> So do you really suggest that 2 *complete* (that is server, libjack,
> headers,  tools..) JACK package would have to be produced? Do you
> really think this would simplify users life?

Do I suggest that user should install either classic jackd environment
or jackdbus one. In both cases they get *same* server and headers. Tools
and libjack will differ minimally. In case of jackdbus you have
additional tool, jack_control and you have libjack autostarting through
dbus.

>>> At the same time it also move the DBUS based acquire/release audio
>>> card code (not you code this time..), that was conditionally compiled
>>> in ALSA backend.
>>>
>>> The result is that all DBUS based code is now grouped and compiled
>>> separated from the main JACK2 tree.
>>
>> This can be achieved in with the trunk approach. In the same way. I
>> dont
>> see how controlplugin refactoring is related to refactoring alsa+pa
>> code. The fact that you are making them both in the controlplugin
>> branch
>> is making them related.
>
> Yep. The point is use this control plugin approach as the way to
> cleanup things that can be cleanp up. And the DBUS acquire/release
> code in ALSA backend was not the most clean thing.

Again, The fact that you are making them both in the controlplugin
branch is making them related. It can be done in trunk without
controplugin refactoring. If not by you then probably by even if it is
in separate branch.

>>> Which I think I try to do with the plugin proposal.  I consider much
>>> better and cleaner to be able to develop and compile a control plugin
>>> only using public headers and linking to libjackserver.so that having
>>> to *patch* the JAC2K source tree (which is still the case in
>>> particular with the  DBUS code in JackPosixServerLaunch.cpp file).
>>
>> Again, one can "develop and compile" jackdbus and other frontends to
>> jackd server through the control API that is already in trunk. As for
>> jack server autostart, this can be solved by launching dbus-send or
>> some
>> custom utility (probably named "jackd").
>
> This is a new proposal AFAICS : can you explain exactly how it would
> work?

see below

>>>> 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.
>>>
>>> In some sense yes, but the new model allows guardian to *just*
>>> install
>>> the what would be so-called "standard" JACK2. In this case no DBUS
>>> stuff would be installed at all. I consider this as a gain. Then DBUS
>>> aware users would install the new so-called DBUS control package and
>>> gain DBUS control, with the possible issues that may stay. But then
>>> those users are hopefully knowing the possible issues (like using
>>> Qjackctl tool along pure DBUS based control tools...)
>>>
>>> But again how could we do better, without  1) kind of fork (like
>>> maintaining a DBUS patched tree) or 2) single jackd/jackdbus package
>>> with the all the problems that actually started this whole DBUS
>>> flamewar or 2) double packaging (one "jackd" based , one "jackdbus"
>>> based package) ?
>>
>> Let me state it clearly. mixing jackd and jackdbus is as bad as mixing
>> jack1 and jack2. If someone has motivation to provide user support for
>> this insane environment - fine. I dont. The most bold arguments of
>> anti-dbus guardians were against libjack.so dynamically linking
>> libdbus.so. This issue can be fixed without the merge of jackd and
>> jackdbus and has nothing to do with it.
>
> Please suggest something concrete (on a git branch or something)

I cant choose what will please guardiands and you. For me, linking to
libjack is fine except if violation of the LGPL license gets proven.

Solution also depends on whether jackdrc will stay as shell scripts or
it will be configuration file. If it stays as shell script (what seems
to be what stagnation in guardian temple suggests), then it can
contain the dbus-send commandline that will start the jack server
through dbus. And this will require NO CHANGE in libjack.so. Of course
this will cause yet another app to write jackdrc (after confirmation
From user). Because LADI will have a component that will check whether
jackdrc is dbus-compatible and if not will allow user option to change
it, maybe it can even salvage settings from jackd commandline there and
push them through D-Bus to configuration manager/storage.

> What about the DBUS code that would stay in ALSA backend?

It should not stay there. It can be part of the jackdbus executable. We
already agreed on IRC that its place is not in the ALSA driver. The
point is where to place it. I think it should be part of jackdbus, you
think it should be part of the dbus control server-side plugin. Right?

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

> Again, The fact that you are making them both in the controlplugin
> branch is making them related. It can be done in trunk without
> controplugin refactoring. If not by you then probably by even if it is
> in separate branch.

is NOT making them related. bah :]

--
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 à 20:25, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>>>>
>>>> Sure, this was the fact also with "jackdbus"  process.
>>>
>>> No it is not. Whom checks for jackd (human, ardour or qjackctl)
>>> will not find jackd as running.
>>
>> If the user uses qjackctl in a JACK + DBUS based setup which we both
>> agree is potentially problematic in any case right?
>
> No. AFAIK qjackctl will be able to stop jackd process assuming it  
> is the
> server while it is just the persistent endpoint. OTOH my proposal  
> solves
> the problem with qjackctl and ardour. My proposal is in the
> guardian/rebels mail and also contains a diagram. Diagram that got no
> responses because it was pusing details that some guardians refuse to
> agree to exist (too complicated, too big, etc). Just because some
> diagram is not oversimplificated and pushing limited POV does not mean
> it is complicated.
>
>>>> It solves the double "jackd" , "jackbus" server incarnation  
>>>> issue and
>>>> it does remove the conditional compilation used in libjack code
>>>> (precisely in JackPosixServerLaunch.cpp file) that use the DBUS  
>>>> mode
>>>> for the client "autostart" feature.
>>>
>>> This issue is result of packaging error. I don't see why anyone will
>>> want to use both classic jackd and jackdbus. I do/did have them
>>> installed both but this is because I know how they (don't)
>>> interoperate. Moreover on the packager oriented wiki page in jack
>>> track
>>> I've clearly stated what bad things that will happen when both
>>> jackd and
>>> jackdbus are mixed. I've made this as an attempt to help packagers
>>> to do
>>> informed decisions and thus please their users. Unfortunately this
>>> did't
>>> work for Fons. I tend to think that this happened because that
>>> documentation was not being pushed enough to packagers and one of  
>>> them
>>> was not aware.
>>
>> So do you really suggest that 2 *complete* (that is server, libjack,
>> headers,  tools..) JACK package would have to be produced? Do you
>> really think this would simplify users life?
>
> Do I suggest that user should install either classic jackd environment
> or jackdbus one. In both cases they get *same* server and headers.  
> Tools
> and libjack will differ minimally. In case of jackdbus you have
> additional tool, jack_control and you have libjack autostarting  
> through
> dbus.

So 2 packages for JACK2, after already the JACK1 and JACK2  
complexity....

>
>>>> At the same time it also move the DBUS based acquire/release audio
>>>> card code (not you code this time..), that was conditionally  
>>>> compiled
>>>> in ALSA backend.
>>>>
>>>> The result is that all DBUS based code is now grouped and compiled
>>>> separated from the main JACK2 tree.
>>>
>>> This can be achieved in with the trunk approach. In the same way. I
>>> dont
>>> see how controlplugin refactoring is related to refactoring alsa+pa
>>> code. The fact that you are making them both in the controlplugin
>>> branch
>>> is making them related.
>>
>> Yep. The point is use this control plugin approach as the way to
>> cleanup things that can be cleanp up. And the DBUS acquire/release
>> code in ALSA backend was not the most clean thing.
>
> Again, The fact that you are making them both in the controlplugin
> branch is making them related. It can be done in trunk without
> controplugin refactoring.

How that? Please explain.

> If not by you then probably by even if it is
> in separate branch.
>
>>>> Which I think I try to do with the plugin proposal.  I consider  
>>>> much
>>>> better and cleaner to be able to develop and compile a control  
>>>> plugin
>>>> only using public headers and linking to libjackserver.so that  
>>>> having
>>>> to *patch* the JAC2K source tree (which is still the case in
>>>> particular with the  DBUS code in JackPosixServerLaunch.cpp file).
>>>
>>> Again, one can "develop and compile" jackdbus and other frontends to
>>> jackd server through the control API that is already in trunk. As  
>>> for
>>> jack server autostart, this can be solved by launching dbus-send or
>>> some
>>> custom utility (probably named "jackd").
>>
>> This is a new proposal AFAICS : can you explain exactly how it would
>> work?
>
> see below
>
>>>>> 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.
>>>>
>>>> In some sense yes, but the new model allows guardian to *just*
>>>> install
>>>> the what would be so-called "standard" JACK2. In this case no DBUS
>>>> stuff would be installed at all. I consider this as a gain. Then  
>>>> DBUS
>>>> aware users would install the new so-called DBUS control package  
>>>> and
>>>> gain DBUS control, with the possible issues that may stay. But then
>>>> those users are hopefully knowing the possible issues (like using
>>>> Qjackctl tool along pure DBUS based control tools...)
>>>>
>>>> But again how could we do better, without  1) kind of fork (like
>>>> maintaining a DBUS patched tree) or 2) single jackd/jackdbus  
>>>> package
>>>> with the all the problems that actually started this whole DBUS
>>>> flamewar or 2) double packaging (one "jackd" based , one "jackdbus"
>>>> based package) ?
>>>
>>> Let me state it clearly. mixing jackd and jackdbus is as bad as  
>>> mixing
>>> jack1 and jack2. If someone has motivation to provide user  
>>> support for
>>> this insane environment - fine. I dont. The most bold arguments of
>>> anti-dbus guardians were against libjack.so dynamically linking
>>> libdbus.so. This issue can be fixed without the merge of jackd and
>>> jackdbus and has nothing to do with it.
>>
>> Please suggest something concrete (on a git branch or something)
>
> I cant choose what will please guardiands and you. For me, linking to
> libjack is fine except if violation of the LGPL license gets proven.
>
> Solution also depends on whether jackdrc will stay as shell scripts or
> it will be configuration file. If it stays as shell script (what seems
> to be what stagnation in guardian temple suggests), then it can
> contain the dbus-send commandline that will start the jack server
> through dbus. And this will require NO CHANGE in libjack.so. Of course
> this will cause yet another app to write jackdrc (after confirmation
> From user). Because LADI will have a component that will check whether
> jackdrc is dbus-compatible and if not will allow user option to change
> it, maybe it can even salvage settings from jackd commandline there  
> and
> push them through D-Bus to configuration manager/storage.
>
>> What about the DBUS code that would stay in ALSA backend?
>
> It should not stay there. It can be part of the jackdbus  
> executable. We
> already agreed on IRC that its place is not in the ALSA driver. The
> point is where to place it. I think it should be part of jackdbus,

How again?

> you
> think it should be part of the dbus control server-side plugin. Right?
>

So I suggest you start a git branch to implement your view. Then we  
can compare real stuff.

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

[Nedko Arnaudov]

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

> So 2 packages for JACK2, after already the JACK1 and JACK2
> complexity....

Not. I think you know about the wiki page we have. The one that
explains packaging approach everybody seems to agree on. It is not 2
packages at all.

>>>>> At the same time it also move the DBUS based acquire/release audio
>>>>> card code (not you code this time..), that was conditionally
>>>>> compiled
>>>>> in ALSA backend.
>>>>>
>>>>> The result is that all DBUS based code is now grouped and compiled
>>>>> separated from the main JACK2 tree.
>>>>
>>>> This can be achieved in with the trunk approach. In the same way. I
>>>> dont
>>>> see how controlplugin refactoring is related to refactoring alsa+pa
>>>> code. The fact that you are making them both in the controlplugin
>>>> branch
>>>> is making them related.

> How that? Please explain.

Control API provides the audio device string that is used for
interraction with PA. Thats whole change that needs to be made outside
of jackdbus, unless I miss something about jack <-> PA cooperation
protocol that is used.

--
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 à 20:47, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>> So 2 packages for JACK2, after already the JACK1 and JACK2
>> complexity....
>
> Not. I think you know about the wiki page we have. The one that
> explains packaging approach everybody seems to agree on. It is not 2
> packages at all.

Do you mean http://trac.jackaudio.org/wiki/SuggestedPackagingApproach ?

I have always think this a overly complex, but I'm not a packager but  
would like to get feddback from others like Fernando?

>
>>>>>> At the same time it also move the DBUS based acquire/release  
>>>>>> audio
>>>>>> card code (not you code this time..), that was conditionally
>>>>>> compiled
>>>>>> in ALSA backend.
>>>>>>
>>>>>> The result is that all DBUS based code is now grouped and  
>>>>>> compiled
>>>>>> separated from the main JACK2 tree.
>>>>>
>>>>> This can be achieved in with the trunk approach. In the same  
>>>>> way. I
>>>>> dont
>>>>> see how controlplugin refactoring is related to refactoring alsa
>>>>> +pa
>>>>> code. The fact that you are making them both in the controlplugin
>>>>> branch
>>>>> is making them related.
>
>> How that? Please explain.
>
> Control API provides the audio device string that is used for
> interraction with PA. Thats whole change that needs to be made outside
> of jackdbus, unless I miss something about jack <-> PA cooperation
> protocol that is used.
>

But when would the ALSA backend  acquire/release code be called?  
Again a real implemention would help.

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

[Nedko Arnaudov]

> Do you mean http://trac.jackaudio.org/wiki/SuggestedPackagingApproach ?
>
> I have always think this a overly complex, but I'm not a packager but
> would like to get feddback from others like Fernando?

Yes, this wiki page. I've talked with ubuntustudio packagers when this
page was created. Of course everybody is free to disagree.

>> Control API provides the audio device string that is used for
>> interraction with PA. Thats whole change that needs to be made outside
>> of jackdbus, unless I miss something about jack <-> PA cooperation
>> protocol that is used.
>>
>
> But when would the ALSA backend  acquire/release code be called?
> Again a real implemention would help.

When jack dbus server is going to start/stop server. And it will stop
the server (according to the spec) when the dbus name is lost.

Problem with real implementation is that i don't have PA and it will be
hard for me to test it. If this will help to abandon controlplugin
complication I will implement the PAX stuff and will try to install PA
on my system.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Rui Nuno Capela]

Nedko Arnaudov wrote:

> Stéphane Letz <letz@...> writes:
>
>> Le 1 juil. 09 à 17:50, Nedko Arnaudov a écrit :
>>
>>> 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.
>> Sure, this was the fact also with "jackdbus"  process.
>
> ... Whom checks for jackd (human, ardour or qjackctl)
> will not find jackd as running.
>

if i may chime in as side-note ;)

qjackctl doesn't look for jackd and never did.

what qjackctl does is just calling jack_client_open() with explicit
JackNoStartServer flag option. if this call fails, qjackctl knows that
jackd (as the jack process server) is not up and running.

again, qjackctl does not look for a running "jackd" command process in
any case.

the only process that gets explicitly stopped by qjackctl is the one it
started through fork+exec("/path/to/jackd", args) by QProcess class
implementation.

cheers
--
rncbc aka Rui Nuno Capela
rncbc@...
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

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

>
>> Do you mean http://trac.jackaudio.org/wiki/ 
>> SuggestedPackagingApproach ?
>>
>> I have always think this a overly complex, but I'm not a packager but
>> would like to get feddback from others like Fernando?
>
> Yes, this wiki page. I've talked with ubuntustudio packagers when this
> page was created. Of course everybody is free to disagree.

Better wait for some feedback.

>
>>> Control API provides the audio device string that is used for
>>> interraction with PA. Thats whole change that needs to be made  
>>> outside
>>> of jackdbus, unless I miss something about jack <-> PA cooperation
>>> protocol that is used.
>>>
>>
>> But when would the ALSA backend  acquire/release code be called?
>> Again a real implemention would help.
>
> When jack dbus server is going to start/stop server. And it will stop
> the server (according to the spec) when the dbus name is lost.
>
> Problem with real implementation is that i don't have PA and it  
> will be
> hard for me to test it. If this will help to abandon controlplugin
> complication I will implement the PAX stuff and will try to install PA
> on my system.
>

I'm fine to see any implementation (or "test"  implementation) that  
can solve the "DBUS code in libjack" issue and improve (basically  
move) the ALSA acquire/release code.

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

[Fernando Lopez-Lezcano]

On Wed, 2009-07-01 at 20:58 +0200, Stéphane Letz wrote:
> Le 1 juil. 09 à 20:47, Nedko Arnaudov a écrit :
>
> > Stéphane Letz <letz@...> writes:
> >
> >> So 2 packages for JACK2, after already the JACK1 and JACK2
> >> complexity....
> >
> > Not. I think you know about the wiki page we have. The one that
> > explains packaging approach everybody seems to agree on.

Everybody??

> > It is not 2 packages at all.
>
> Do you mean http://trac.jackaudio.org/wiki/SuggestedPackagingApproach ?
>
> I have always think this a overly complex, but I'm not a packager but  
> would like to get feedback from others like Fernando?

On Wed, 2009-07-01 at 22:16 +0300, Nedko Arnaudov wrote:
> Yes, this wiki page. I've talked with ubuntustudio packagers when this
> page was created. Of course everybody is free to disagree.

I see, so "everybody agrees" is actually "ubuntustudio packagers agree".

This is the first time this url about packaging suggestions has been
posted to jack-devel or discussed.

At this point I'm completely confused and will have to find time to
reread the whole thread before commenting further. It will take time to
sort out pure technical issues from emotional issues, which seem to
abound.

One quick question. Paul wrote:
> And I'll repeat: JACK will not depend on non-POSIX interfaces for any
> essential functions unless the platform requires it, which it does not
> in this case.

So, how does this work in both approaches?

-- Fernando

PS: this is what I expressed as a preference for packaging:
On Mon, 2009-06-15 at 19:46 -0700, Fernando Lopez-Lezcano wrote:
> I don't remember if I have explicitly expressed my preferences with my
> packager's hat on.
>
> What I want to be able to do as a packager is, I think, simple (and I
> want the same thing as a user!).
>
> I want users to be able to choose whether to run jackd as before (ie:
no
> dbus), or run jackd with a dbus connection. I don't want to force them
> to use either mode. The choice could be made with a jackd runtime
switch
> (in which case I would like to be able to select at compile time which
> mode is the default), or it could be made by installing an additional
> package (in which case installing an additional package would
magically
> add the dbus functionality and removing it would remove that
> functionality[*]). I think I would prefer a runtime switch.
>
> In other words I want the possibility to transition from one mode to
the
> other and back, and I want that possibility to be in the hands of each
> user and not just in my hands as a packager.
>
> I don't care that much about how this is accomplished.
>
> [*] BTW, "installing an additional package" means not modifying any of
> the files of the original base jack-audio-connection-kit package but
> rather adding something (shared library?) that is recognized by the
> existing jackd and automatically adds the functionality.


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

[Nedko Arnaudov]

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

> One quick question. Paul wrote:
>> And I'll repeat: JACK will not depend on non-POSIX interfaces for any
>> essential functions unless the platform requires it, which it does not
>> in this case.
>
> So, how does this work in both approaches?

IMHO it is equaly true for both controlplugin and jackdbus
approaches. Not that I care about the non-POSIX dogma...

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Nedko Arnaudov]

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

> qjackctl doesn't look for jackd and never did.
>
> what qjackctl does is just calling jack_client_open() with explicit
> JackNoStartServer flag option. if this call fails, qjackctl knows that
> jackd (as the jack process server) is not up and running.
>
> again, qjackctl does not look for a running "jackd" command process in
> any case.
>
> the only process that gets explicitly stopped by qjackctl is the one it
> started through fork+exec("/path/to/jackd", args) by QProcess class
> implementation.

Thanks for the clarification.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Fernando Lopez-Lezcano]

On Wed, 2009-07-01 at 23:15 +0300, Nedko Arnaudov wrote:

> Fernando Lopez-Lezcano <nando@...> writes:
>
> > One quick question. Paul wrote:
> >> And I'll repeat: JACK will not depend on non-POSIX interfaces for any
> >> essential functions unless the platform requires it, which it does not
> >> in this case.
> >
> > So, how does this work in both approaches?
>
> IMHO it is equaly true for both controlplugin and jackdbus
> approaches.

Thanks.
I have not yet read the thread.

> Not that I care about the non-POSIX dogma...

We all know that by now. You have made it clear. So, could we just
_please_ stick to technical issues from now on? Please?

-- Fernando


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

[Fons Adriaensen-2]

On Wed, Jul 01, 2009 at 06:30:28PM +0200, Stéphane Letz wrote:

> I hope some of the previous arguments explain the benefits.

Having read all the messages in this thread after a long and
busy day, the only conclusion I can arrive at is that all this
seems to be completely upside down.

* I do accept that (for the benefit of desktop users who want
  to see things happen automagically instead of keeping them
  into their own hands), some 'higher' entity, e.g. dbus and
  friends, has to take control of Jack.

* This does *not* imply that Jack should be aware of this, or
  cooperate in any way to activate this higher level of control.

* This higher level can be started explicitly by the user, or
  it can be done for him/her by his/her desktop environment
  when that is started. There is no need to do this when Jack
  is called directly.
 
* If programs want to autostart Jack controlled by dbus,
  then **they should call dbus, not Jack**. If you want
  the boss to control things you talk to the boss, not to
  his slaves.

* Trying to make Jack do things that should be done by the
  surrounding environment or by applications - i.e. expect
  Jack to arrange for itself to be controlled by dbus, or
  any other higher level manager, means turning the normal
  flow of control upside down. It can be made to work, but
  even if it works perfectly it is a dirty solution, and not
  somehting that will stand the test of time.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

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

[Patrick Shirkey]

On 07/02/2009 04:55 AM, Fons Adriaensen wrote:

On Wed, Jul 01, 2009 at 06:30:28PM +0200, Stéphane Letz wrote:

  

I hope some of the previous arguments explain the benefits.
    

Having read all the messages in this thread after a long and
busy day, the only conclusion I can arrive at is that all this
seems to be completely upside down.

* I do accept that (for the benefit of desktop users who want
  to see things happen automagically instead of keeping them
  into their own hands), some 'higher' entity, e.g. dbus and
  friends, has to take control of Jack.

* This does *not* imply that Jack should be aware of this, or
  cooperate in any way to activate this higher level of control. 

* This higher level can be started explicitly by the user, or
  it can be done for him/her by his/her desktop environment
  when that is started. There is no need to do this when Jack
  is called directly.
  
* If programs want to autostart Jack controlled by dbus,
  then **they should call dbus, not Jack**. If you want
  the boss to control things you talk to the boss, not to
  his slaves. 

* Trying to make Jack do things that should be done by the 
  surrounding environment or by applications - i.e. expect 
  Jack to arrange for itself to be controlled by dbus, or
  any other higher level manager, means turning the normal
  flow of control upside down. It can be made to work, but
  even if it works perfectly it is a dirty solution, and not
  somehting that will stand the test of time.

  

To clarify do I understand correctly that this comes down to jack server (not jackd) starting prior to dbus and then a program that uses dbus for communication with (ie PA) jack being added to the system?

Hence a dbus module which could be packaged seperately would solve Fons issue with compile time deps and still allow dbus communication.

However adding a plugin/module system to jack just for dbus seems to be a lot of extra work. Are there any other cases that would benefit from this approach?

It would seem that the simpler way to handle it would be for all mainstream packaging environments that also have pa and dbus to provide a package with dbus enabled at compile time and for another distro to provide a non dbus package. However then we would then have jack, jack2 and jack2-dbus packages as well as roll your own, which creates a dependency nightmare for packagers and users.  Although the most likely outcome is that all major distros will provide jack2-dbus and be done with it. In this case people with requirements such as Fons will just have to roll their own with arch, gentoo or LFS.

How many other apps use dbus to communicate with jack? How many are likely to use it in the future once support is in place? If an app uses PA then it is unlikely to want to talk to jack so afaict currently the only apps that use dbus are PA and LADI. Those are pretty big guns to be sure with no doubt more to come in the future but it certainly feels like we have been forced to accomodate their needs by having to add dbus support for jack.

It would appear that the JACK team are most likely to find a workable solution to integrate dbus but some people are not sure that it is necessary.

Given all the above I say it is 100% necessary that jack and dbus integrate cleanly but as an optional compile time dependency.

Can we now agree to that so everyone can move forward with the integration debate?



Cheers.








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

[Paul Davis]

On Wed, Jul 1, 2009 at 5:55 PM, Fons Adriaensen<fons@...> wrote:

> * I do accept that (for the benefit of desktop users who want
>  to see things happen automagically instead of keeping them
>  into their own hands), some 'higher' entity, e.g. dbus and
>  friends, has to take control of Jack.

Phew! :)

> * This does *not* imply that Jack should be aware of this, or
>  cooperate in any way to activate this higher level of control.

Agreed that it does not imply this. It may be, however, that its
simpler, more robust and generally easier to get JACK involved in some
relatively limited way.

> * This higher level can be started explicitly by the user, or
>  it can be done for him/her by his/her desktop environment
>  when that is started. There is no need to do this when Jack
>  is called directly.

Agreed. I don't think any of the control API proposal as it currently
stands is in any opposition to this. If you simply start JACK in the
normal way, it will just start up. If you specify other arguments
(specifically ones that tell it to load a control plugin that wants to
take control of things), then it will start as a process, but not as
a JACK server.

> * If programs want to autostart Jack controlled by dbus,
>  then **they should call dbus, not Jack**. If you want
>  the boss to control things you talk to the boss, not to
>  his slaves.

The problem here is that there is no thing call "dbus" that really
*does* anything. To send out an IPC request via any means (DBus or
anything else) requires some kind of pre-existing end-point. That
could be a completely new program than JACK, or it could be JACK
started with parameters that told it to load a control plugin that
waits as the end-point for the command(s) to start/stop etc.

> * Trying to make Jack do things that should be done by the
>  surrounding environment or by applications - i.e. expect
>  Jack to arrange for itself to be controlled by dbus, or
>  any other higher level manager, means turning the normal
>  flow of control upside down. It can be made to work, but
>  even if it works perfectly it is a dirty solution, and not
>  somehting that will stand the test of time.

I don't see this. If you don't load any control plugins, you get
regular JACK. If you explicitly load those plugins, you get a JACK
controllable by whatever the plugin responds to (DBus, OSC, whatever).

As Rui has noted, nothing that exists today tests for the presence of
a JACK server by looking in the process table - you test for JACK by
attempting to connect with the server. This means that there is really
very little conflict implicit in the existence of a process called
"jackd" that has not *yet* become a JACK server or is not *currently*
a JACK server.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org