Server control plug-ins proposal

[Nedko Arnaudov]

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

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

I've moved the acquire/release device code:

http://repo.or.cz/w/jack2.git?a=shortlog;h=refs/heads/dbus-reservation

It has no support for multiple devices yet.

I have also fixed bug in the card number detection that was happening
here. On my system I have "default" device linked to the real hardware
device I want to use. And most often it is linked to "hw:1". Both
snd_card_get_index() and atoi() were failing on and this was resulting
in wrong device Audio0 being acquired instead of Audio1.

no dbus code in libjack is easy too, user that want autostart will need
to have this commandline in ~/.jackdrc:

dbus-send --session --print-reply=yes --dest=org.jackaudio.service/org/jackaudio/Controller org.jackaudio.JackControl.StartServer

Still please dont remove the libdbus code in libjack! Make it disabled
by default. And give the packagers choice whether they want to rely on
~/.jackdrc or libjack that directly uses libdbus to start
jack. Especially I want to use autolaunching through libdbus and not
through ~/.jackdrc.

--
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 à 23:55, Fons Adriaensen a écrit :

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

Sorry Fons, but I don't think those kind of "fuzzy" comments helps a  
lot. Either you come up with a concrete technically based proposal, or  
we'll have to continue the discussion on the 2 different  
implementations that have emerged up until now.

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

[Stéphane Letz]

Le 2 juil. 09 à 01:16, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>>>>> 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.
>
> I've moved the acquire/release device code:
>
> http://repo.or.cz/w/jack2.git?a=shortlog;h=refs/heads/dbus-reservation
>
> It has no support for multiple devices yet.
>
> I have also fixed bug in the card number detection that was happening
> here. On my system I have "default" device linked to the real hardware
> device I want to use. And most often it is linked to "hw:1". Both
> snd_card_get_index() and atoi() were failing on and this was resulting
> in wrong device Audio0 being acquired instead of Audio1.
>
> no dbus code in libjack is easy too, user that want autostart will  
> need
> to have this commandline in ~/.jackdrc:
>
> dbus-send --session --print-reply=yes --dest=org.jackaudio.service/
> org/jackaudio/Controller org.jackaudio.JackControl.StartServer

Thanks for the concrete proposal.
>
> Still please dont remove the libdbus code in libjack! Make it disabled
> by default. And give the packagers choice whether they want to rely on
> ~/.jackdrc or libjack that directly uses libdbus to start
> jack. Especially I want to use autolaunching through libdbus and not
> through ~/.jackdrc.

So basically you're asking to keep a "back door" so that  we'll end up  
with 2 different versions of libjack.so? So the issue will move on  
packagers and we'll possibly have several packages with this "litlle"  
difference in libjack?  Packagers comments? Fernando?

Sorry but for me this does not make sense at all.

Anyway I'll look at dbus-reservation git branch and try to summarize  
the 2 technical proposal that have emerged.

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

[Fons Adriaensen-2]

On Thu, Jul 02, 2009 at 09:43:32AM +0200, Stéphane Letz wrote:

> Le 1 juil. 09 à 23:55, Fons Adriaensen a écrit :
>
>> 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.
>>
>
> Sorry Fons, but I don't think those kind of "fuzzy" comments helps a lot.
> Either you come up with a concrete technically based proposal, or we'll
> have to continue the discussion on the 2 different implementations that
> have emerged up until now.

The may appear 'fuzzy' because the point is to show a
general principle. This being that

If A is to be controlled by B then

- This does not require A to have interfaces or plugins
  specific to B. It only requires A to have an API that
  allows B (or others) to control it.

- The initiative to control A should be with B, A does
  not even have to know who is controlling it.

- If a user or application wants to autolaunch A and have
  it controlled by B, he/she/it should talk to B, and not A.


In other words, Jack does not require a dbus plugin any
more than it requires a qjackctl plugin.

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

[Stéphane Letz]

L

> The may appear 'fuzzy' because the point is to show a
> general principle. This being that
>
> If A is to be controlled by B then
>
> - This does not require A to have interfaces or plugins
>  specific to B. It only requires A to have an API that
>  allows B (or others) to control it.
>
> - The initiative to control A should be with B, A does
>  not even have to know who is controlling it.

So you're suggesting having the control API  available using IPC yes?

>
> - If a user or application wants to autolaunch A and have
>  it controlled by B, he/she/it should talk to B, and not A.

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?

>
>
> In other words, Jack does not require a dbus plugin any
> more than it requires a qjackctl plugin.
>
> Ciao,
>


I can try to concretely implement this 3rd proposal in another git  
branch, assuming I grasp everything of your proposal correctly.

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

[Paul Davis]

On Thu, Jul 2, 2009 at 4:45 AM, Fons Adriaensen<fons@...> wrote:
>
> In other words, Jack does not require a dbus plugin any
> more than it requires a qjackctl plugin.

Fons, DBus is not a controlling entity, its an IPC protocol in the
same way that OSC is. How does it make sense to say "JACK can be
controlled by OSC even though it doesn't know anything about OSC".
This is only possible by adding *another* IPC mechanism.

We did discuss this recently, and it was clear that there are a whole
host design issues that arise from this approach too. I don't believe
you or anyone else came up with concrete ideas on how to solve them
effectively. The main issue that I recall is that if the IPC protocol
used is JACK's own existing one, there has be a decision about whether
or not there is a persistent endpoint or not. If there is no
persistent endpoint, then there has to be some facility for
"broadcasting" the arrival of a new end point, so that tools which
want to display status can know what has happened. If there is a
persistent endpoint, then its not entirely clear why it shouldn't be
able to understand protocols like OSC or DBus with the help of
run-time selected plugins, rather than require that they be translated
by another process.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Thu, Jul 02, 2009 at 08:24:44AM -0400, Paul Davis wrote:
> On Thu, Jul 2, 2009 at 4:45 AM, Fons Adriaensen<fons@...> wrote:
> >
> > In other words, Jack does not require a dbus plugin any
> > more than it requires a qjackctl plugin.
>
> Fons, DBus is not a controlling entity, its an IPC protocol in the
> same way that OSC is. How does it make sense to say "JACK can be
> controlled by OSC even though it doesn't know anything about OSC".
> This is only possible by adding *another* IPC mechanism.

No, all it takes is a separate app using the control API and
translating it to OSC, dbus, or Chinese.

Jack2 already has the control API, maybe some things need to
be added there, but that should be it.

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

[Paul Davis]

On Thu, Jul 2, 2009 at 4:55 PM, Fons Adriaensen<fons@...> wrote:

> On Thu, Jul 02, 2009 at 08:24:44AM -0400, Paul Davis wrote:
>> On Thu, Jul 2, 2009 at 4:45 AM, Fons Adriaensen<fons@...> wrote:
>> >
>> > In other words, Jack does not require a dbus plugin any
>> > more than it requires a qjackctl plugin.
>>
>> Fons, DBus is not a controlling entity, its an IPC protocol in the
>> same way that OSC is. How does it make sense to say "JACK can be
>> controlled by OSC even though it doesn't know anything about OSC".
>> This is only possible by adding *another* IPC mechanism.
>
> No, all it takes is a separate app using the control API and
> translating it to OSC, dbus, or Chinese.

the control API relies on some kind of IPC mechanism, as i noted in my
previous message. just as OSC doesn't actually have to be delivered
via UDP, the definition of the control API does not actually say how a
control application/plugin/whatever interacts with the server.

> Jack2 already has the control API, maybe some things need to
> be added there, but that should be it.

the existence of a/the control API does not solve the issue of
pre-existing endpoints. got a suggestion there?
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Patrick Shirkey <pshirkey@...> writes:

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

This was the suggested packaging before jackdbus was forcibly packaged
in the main package and delivered to Fons.

http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

It looks everybody agrees that this will not happen again. Unless some
packager for other distro stays unaware of the dbus rebels vs guardians
war. What we could do to avoid such packaging problems in future is to
give more obvious pointer(s) to the suggested packaging approach
document (whethever it is). It can be included it in the distribution
tarball.

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

I'm wondering the same. So far I didn't saw any other cases.

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

Very good point! Major distros include PA and thus will probably want
the jack-dbus cooperation mechanism that is available only through
jack2-dbus package (regardless of whether it is controlplugin or
jackdbus implementation).

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

I like that (l)patchage, LASH and laditools are getting the LADI union
shape in your eyes :)

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

Indeed. This worries me more than controlplugin/jackdbus stuff. Because
last time it caused FUD war and I dont want this to happen again. If we
don't solve this issue then even if jackdbus rebel camp and guardian
temple roles get exchanged, we will probably have anti-dbus rebels
sooner or later.

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

This was the case from day zero (dbus.patch for jack1). It was and
should be compile time option. Even if we change the default to
jackdbus, disabling it should be available for classic jackd lovers.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Fons Adriaensen-2]

On Thu, Jul 02, 2009 at 05:15:03PM -0400, Paul Davis wrote:

> > Jack2 already has the control API, maybe some things need to
> > be added there, but that should be it.
>
> the existence of a/the control API does not solve the issue of
> pre-existing endpoints. got a suggestion there?

Yes, I posted it somewhere mid May IIRC.

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

[Fernando Lopez-Lezcano]

On Fri, 2009-07-03 at 06:41 +0300, Nedko Arnaudov wrote:
> Patrick Shirkey <pshirkey@...> writes:
>
> > Hence a dbus module which could be packaged seperately would solve
> > Fons issue with compile time deps and still allow dbus communication.
>
> This was the suggested packaging before jackdbus was forcibly packaged
> in the main package and delivered to Fons.

I don't understand, could you clarify? ACAICT there can't be a separate
dbus module in your architecture, right? It is just one binary.

> http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
>
> It looks everybody agrees that this will not happen again. Unless some
> packager for other distro stays unaware of the dbus rebels vs guardians
> war.

[OT: Sorry, but there is no war. This is just a discussion in a mailing
list. IMO "rebels" and "guardians" are just labels you came up with, and
regretfully they carry emotional connotations that don't help achieving
objective discussions.]

> What we could do to avoid such packaging problems in future is to
> give more obvious pointer(s) to the suggested packaging approach
> document (whethever it is). It can be included it in the distribution
> tarball.
>
> > 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?
>
> I'm wondering the same. So far I didn't saw any other cases.
>
> > 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.
>
> Very good point! Major distros include PA and thus will probably want
> the jack-dbus cooperation mechanism that is available only through
> jack2-dbus package (regardless of whether it is controlplugin or
> jackdbus implementation).
>
> > 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.
>
> I like that (l)patchage, LASH and laditools are getting the LADI union
> shape in your eyes :)
>
> > 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.
>
> Indeed. This worries me more than controlplugin/jackdbus stuff. Because
> last time it caused FUD war and I dont want this to happen again. If we
> don't solve this issue then even if jackdbus rebel camp and guardian
> temple roles get exchanged, we will probably have anti-dbus rebels
> sooner or later.
>
> > Given all the above I say it is 100% necessary that jack and dbus
> > integrate cleanly but as an optional compile time dependency.
>
> This was the case from day zero (dbus.patch for jack1). It was and
> should be compile time option. Even if we change the default to
> jackdbus, disabling it should be available for classic jackd lovers.

Yes, of course it should be a compile time option! If you compile with
the option it should be possible to not use dbus at runtime (choice). My
(incorrect?) understanding is that that is not possible.

The current choices I understand you give users if the jackdbus option
is compiled in, and operation without dbus is needed, are:

- compile your own
- switch to another distro

Both are IMO inadequate.

-- 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:41 +0300, Nedko Arnaudov wrote:
>> Patrick Shirkey <pshirkey@...> writes:
>>
>> > Hence a dbus module which could be packaged seperately would solve
>> > Fons issue with compile time deps and still allow dbus communication.
>>
>> This was the suggested packaging before jackdbus was forcibly packaged
>> in the main package and delivered to Fons.
>
> I don't understand, could you clarify? ACAICT there can't be a separate
> dbus module in your architecture, right? It is just one binary.

It *is* separate.

>> > Given all the above I say it is 100% necessary that jack and dbus
>> > integrate cleanly but as an optional compile time dependency.
>>
>> This was the case from day zero (dbus.patch for jack1). It was and
>> should be compile time option. Even if we change the default to
>> jackdbus, disabling it should be available for classic jackd lovers.
>
> Yes, of course it should be a compile time option! If you compile with
> the option it should be possible to not use dbus at runtime (choice). My
> (incorrect?) understanding is that that is not possible.
>
> The current choices I understand you give users if the jackdbus option
> is compiled in, and operation without dbus is needed, are:
>
> - compile your own
> - switch to another distro
>
> Both are IMO inadequate.

No, you dont understand. In fact you do understand what choices I give
to users because you've choosen them. You have enabled dbus in jack2
that you packaged and you know for sure that such option exists and that
dbus is disabled by default. So stop wasting my time. I'll not reply to
your mails if they use this FUD BS I see here

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Paul Davis]

On Fri, Jul 3, 2009 at 2:04 PM, Nedko Arnaudov<nedko@...> wrote:
>
> No, you dont understand. In fact you do understand what choices I give
> to users because you've choosen them. You have enabled dbus in jack2
> that you packaged and you know for sure that such option exists and that
> dbus is disabled by default. So stop wasting my time. I'll not reply to
> your mails if they use this FUD BS I see here

this level of impoliteness is getting impossible to tolerate.

fernando has asked a legitimate question from his position as (1) a
packager of JACK who has to make decisions about which compile options
to use and (2) a user & administrator of machines running JACK.

if support for any particular control mechanism is compiled into a
JACK package, and this mechanism "takes over" the startup mechanism
for the JACK server, then anyone who wants JACK without that mechanism
needs a different package/self-built system.

so, in building a package with the mechanism compiled into the JACK
makes a pretty distinct choice for end-users, one that may not be
appropriate for packagers to make.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Paul Davis <paul@...> writes:

> On Fri, Jul 3, 2009 at 2:04 PM, Nedko Arnaudov<nedko@...> wrote:
>>
>> No, you dont understand. In fact you do understand what choices I give
>> to users because you've choosen them. You have enabled dbus in jack2
>> that you packaged and you know for sure that such option exists and that
>> dbus is disabled by default. So stop wasting my time. I'll not reply to
>> your mails if they use this FUD BS I see here
>
> this level of impoliteness is getting impossible to tolerate.
>
> fernando has asked a legitimate question from his position as (1) a
> packager of JACK who has to make decisions about which compile options
> to use and (2) a user & administrator of machines running JACK.
>
> if support for any particular control mechanism is compiled into a
> JACK package, and this mechanism "takes over" the startup mechanism
> for the JACK server, then anyone who wants JACK without that mechanism
> needs a different package/self-built system.
>
> so, in building a package with the mechanism compiled into the JACK
> makes a pretty distinct choice for end-users, one that may not be
> appropriate for packagers to make.

No this is not in my proposal. So please read my "proposal" as described
by Stephane and comment again. Sorry but I don't see reason to continue
wasting my time if ppl dont read what I and Stephane are writing about
the two "proposals".

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Paul Davis]

On Fri, Jul 3, 2009 at 2:18 PM, Nedko Arnaudov<nedko@...> wrote:
> Paul Davis <paul@...> writes:

>> if support for any particular control mechanism is compiled into a
>> JACK package, and this mechanism "takes over" the startup mechanism
>> for the JACK server, then anyone who wants JACK without that mechanism
>> needs a different package/self-built system.
>>
>> so, in building a package with the mechanism compiled into the JACK
>> makes a pretty distinct choice for end-users, one that may not be
>> appropriate for packagers to make.
>
> No this is not in my proposal. So please read my "proposal" as described
> by Stephane and comment again. Sorry but I don't see reason to continue
> wasting my time if ppl dont read what I and Stephane are writing about
> the two "proposals".

I read it the first time it arrived, and I've just re-read the whole
thread. Unless I've missed something, your most concrete proposal
about this was as follows, in response to Stephane:

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

I am not certain that I can correctly parse this, but my impression is
that you are in fact advocating the idea that a packager should or
could make two different packages available ("jackd" and "jackdbus")
and that a user would have to (a) choose which one they wanted and (b)
ensure that they never installed both of them. If I am misinterpreting
what you wrote above, please correct me.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Paul Davis <paul@...> writes:

> On Fri, Jul 3, 2009 at 2:18 PM, Nedko Arnaudov<nedko@...> wrote:
>> Paul Davis <paul@...> writes:
>
>>> if support for any particular control mechanism is compiled into a
>>> JACK package, and this mechanism "takes over" the startup mechanism
>>> for the JACK server, then anyone who wants JACK without that mechanism
>>> needs a different package/self-built system.
>>>
>>> so, in building a package with the mechanism compiled into the JACK
>>> makes a pretty distinct choice for end-users, one that may not be
>>> appropriate for packagers to make.
>>
>> No this is not in my proposal. So please read my "proposal" as described
>> by Stephane and comment again. Sorry but I don't see reason to continue
>> wasting my time if ppl dont read what I and Stephane are writing about
>> the two "proposals".
>
> I read it the first time it arrived, and I've just re-read the whole
> thread. Unless I've missed something, your most concrete proposal
> about this was as follows, in response to Stephane:
>
> -------------------------------------
>> 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.
> ----------------------------------------
>
> I am not certain that I can correctly parse this, but my impression is
> that you are in fact advocating the idea that a packager should or
> could make two different packages available ("jackd" and "jackdbus")
> and that a user would have to (a) choose which one they wanted and (b)
> ensure that they never installed both of them. If I am misinterpreting
> what you wrote above, please correct me.

Maybe you've reread some other mail then.

From Stephane's mail:

----------------------------------------------------------------

Proposal 1 (Nedko):

[snip]

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.

----------------------------------------------------------------

This means that with both proposals there is no dependency on libdbus in
libjack. Is it clear now?

As for two packages, I think it is better to not mix dbus and non-dbus
variants. Me and Stephane agreed that the issues that arise are dont
depend on whether jackdbus or controlplugin proposal is used. If you
want I can cite where we agreed on this.

Whether those issues should be avoided by conflicting packages or
not is another story and it has nothing to do with two proposals
(jackdbus and controlplugin).

As for *request* for libdbus dependency in libjack, this is for usage in
pure dbus systems. And I want it to be in the codebase just to make
things simpler for LADI. It is request not proposal. And a request one
that I've never been bold about. It will make LADI simpler because there
will be no need to check users ~/.jackdrc and to suggest to override
it. If you want, I can cite in what previous mail I've said this too.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Fons Adriaensen-2]

On Thu, Jul 02, 2009 at 05:15:03PM -0400, Paul Davis wrote:

> the existence of a/the control API does not solve the issue of
> pre-existing endpoints. got a suggestion there?

Nothing new except for the two figures wich you will
find on <http://www.kokkinizita.net/linuxaudio/downloads>.


See jack1.pdf.
--------------

This shows the general idea.

'jack_audio_server' is more or less what we know as jackd
today.

'jack_control_daemon' is the new thing.

* It is started by the runlevel scripts as a service.
  If it isn't running there's no jack.

* It waits for clients to register, which they do in the
  same way as jack apps register with the current jackd.

* It provides the control API to registered clients.
  This includes discovery, configuration, starting
  and stopping of any number of 'jack_audio_server(s)'.

  It provides optional callbacks allowing clients
  to be informed of

    - jack_audio_server(s) starting, stopping,
      reporting errors, etc.
    - autolauch requests from applications.
    - possibly other events.

* It is the *only* entity able/allowed to start or
  terminate a jack_audio_server.

* It does *not* provide any persistence of configuration.

* There would in most cases be just one control client,
  but the API should allow for more to co-exist.

The rest is fairly standard.


See jack2.pdf.
--------------

This shows the control flow when an application wants
to launch a new jack_audio_server.

1. Libjack detects that the required jack_audio_server
   does not exist (or none exists at all), and diverts
   the call to jack_control_daemon.

2. Jack_control_daemon calls back to any of its clients
   that have requested to be informed of autolaunch.
   
3. Control clients either ignore the callback, or decide
   to configure a new jack_audio_server.

4. The control daemon starts the new jack_audio_server.

If no clients are interested, the control daemon starts
a default server (based on ~/.jackdrc).

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

[Nedko Arnaudov]

Fons Adriaensen <fons@...> writes:

> On Thu, Jul 02, 2009 at 05:15:03PM -0400, Paul Davis wrote:
>
>> the existence of a/the control API does not solve the issue of
>> pre-existing endpoints. got a suggestion there?
>
> Nothing new except for the two figures wich you will
> find on <http://www.kokkinizita.net/linuxaudio/downloads>.
>
>
> See jack1.pdf.
> --------------
>
> This shows the general idea.
>
> 'jack_audio_server' is more or less what we know as jackd
> today.
>
> 'jack_control_daemon' is the new thing.
>
> * It is started by the runlevel scripts as a service.
>   If it isn't running there's no jack.

This is not bad thing and I like this approach. jackdbus does something
similar but at desktop session level. Extending it to boot level is good
goal IMHO. If not changing it to boot level for all cases, JACK can at
least (should) allow it.

> * It waits for clients to register, which they do in the
>   same way as jack apps register with the current jackd.
>
> * It provides the control API to registered clients.
>   This includes discovery, configuration, starting
>   and stopping of any number of 'jack_audio_server(s)'.
>
>   It provides optional callbacks allowing clients
>   to be informed of
>
>     - jack_audio_server(s) starting, stopping,
>       reporting errors, etc.
>     - autolauch requests from applications.
>     - possibly other events.

If reinventing wheels is the only option because only posix stuff must
be used, then this is then only way I guess.

> * It is the *only* entity able/allowed to start or
>   terminate a jack_audio_server.

Good, this solves some of the problems I have with current classic
infrastructure. But we need at least ardour and qjackctl to adopt this
new system.

> * It does *not* provide any persistence of configuration.

Does it allow configuring the server (without persistency)? From your
comments bellow, I think it does, right?

> * There would in most cases be just one control client,
>   but the API should allow for more to co-exist.
>
> The rest is fairly standard.

I agree.

> See jack2.pdf.
> --------------
>
> This shows the control flow when an application wants
> to launch a new jack_audio_server.
>
> 1. Libjack detects that the required jack_audio_server
>    does not exist (or none exists at all), and diverts
>    the call to jack_control_daemon.
>
> 2. Jack_control_daemon calls back to any of its clients
>    that have requested to be informed of autolaunch.
>    
> 3. Control clients either ignore the callback, or decide
>    to configure a new jack_audio_server.
>
> 4. The control daemon starts the new jack_audio_server.
>
> If no clients are interested, the control daemon starts
> a default server (based on ~/.jackdrc).

If we have such massive rewrite to actually happen jackdbus interfaces
can be integrated in 'jack_control_daemon'. Also such amount of work
that you propose will solve in much more elegant way the autloaunching
problem that some ppl have.

Still I don't think mixing different infrastructure models at runtime is
good thing. It complicates the codebase thus requiring more maintenance
effort and I don't see how it helps because same end-user requirements
can be achieved at compile time / packaging level. I.e. IMHO users will
either want OSC control (for dedicated boxes), dbus control (for linux
desktop) or qjackctl/classic approach (for tradition
beleivers). Allowing all of them mixed is call for trouble and will
"cost" a lot to the development team.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Fons Adriaensen-2]

On Sat, Jul 04, 2009 at 04:24:29PM +0300, Nedko Arnaudov wrote:

> Fons Adriaensen <fons@...> writes:
>
> > On Thu, Jul 02, 2009 at 05:15:03PM -0400, Paul Davis wrote:
> >
> >> the existence of a/the control API does not solve the issue of
> >> pre-existing endpoints. got a suggestion there?
> >
> > Nothing new except for the two figures wich you will
> > find on <http://www.kokkinizita.net/linuxaudio/downloads>.
> >
> >
> > See jack1.pdf.
> > --------------
> >
> > This shows the general idea.
> >
> > 'jack_audio_server' is more or less what we know as jackd
> > today.
> >
> > 'jack_control_daemon' is the new thing.
> >
> > * It is started by the runlevel scripts as a service.
> >   If it isn't running there's no jack.
>
> This is not bad thing and I like this approach. jackdbus does something
> similar but at desktop session level. Extending it to boot level is good
> goal IMHO. If not changing it to boot level for all cases, JACK can at
> least (should) allow it.

This covers my use case which involves a number of headless
'slave' machines which I want to control from a single unified
GUI on the main machine. There is no 'session' on the remote
machines.

On a normal system the jack_control_daemon would be started
by the runlevel scripts, while a dbus control client would
be created when a user does a local desktop login. So when
the user sees his desktop everything is in place.
 

> > * It waits for clients to register, which they do in the
> >   same way as jack apps register with the current jackd.
> >
> > * It provides the control API to registered clients.
> >   This includes discovery, configuration, starting
> >   and stopping of any number of 'jack_audio_server(s)'.
> >
> >   It provides optional callbacks allowing clients
> >   to be informed of
> >
> >     - jack_audio_server(s) starting, stopping,
> >       reporting errors, etc.
> >     - autolauch requests from applications.
> >     - possibly other events.
>
> If reinventing wheels is the only option because only posix stuff must
> be used, then this is then only way I guess.

It's not reinvented but reused. The client registration
and callback mechanisms already exist in 'classic' jack.
Having the IPC between audio apps and the audio server
on one side, and the IPC between the control daemon and
its clients on the other use the same infrastructure
is what makes it possible to divert a jack_client_open()
to the control daemon when the audio server does not
exist.

> > * It is the *only* entity able/allowed to start or
> >   terminate a jack_audio_server.
>
> Good, this solves some of the problems I have with current classic
> infrastructure. But we need at least ardour and qjackctl to adopt this
> new system.
>
> > * It does *not* provide any persistence of configuration.
>
> Does it allow configuring the server (without persistency)? From your
> comments bellow, I think it does, right?

See above: discovery, configuration, starting and stopping
of the audio servers. So, yes. That's why it exists !

> > * There would in most cases be just one control client,
> >   but the API should allow for more to co-exist.
> >
> > The rest is fairly standard.
>
> I agree.
>
> > See jack2.pdf.
> > --------------
> >
> > This shows the control flow when an application wants
> > to launch a new jack_audio_server.
> >
> > 1. Libjack detects that the required jack_audio_server
> >    does not exist (or none exists at all), and diverts
> >    the call to jack_control_daemon.
> >
> > 2. Jack_control_daemon calls back to any of its clients
> >    that have requested to be informed of autolaunch.
> >    
> > 3. Control clients either ignore the callback, or decide
> >    to configure a new jack_audio_server.
> >
> > 4. The control daemon starts the new jack_audio_server.
> >
> > If no clients are interested, the control daemon starts
> > a default server (based on ~/.jackdrc).
>
> If we have such massive rewrite to actually happen jackdbus interfaces
> can be integrated in 'jack_control_daemon'.

No, a jack system must not have a dbus dependency
and be fully functional without dbus (provided there
is _some_ control client).

This is rather essential. The interface to the control
daemon is provided by libjack, just as it is for audio
clients. On top of that you build whatever you want, but
it remains external.

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

[Fons Adriaensen-2]

On Sat, Jul 04, 2009 at 03:32:00PM +0200, Stéphane Letz wrote:

> Sorry, don't see the PDF files??
>
> Thanks

Oops, didn't update the index.html. Meanwhile you can
wget them of course.

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