Re: [LAD] jack2's dbus name

On Mon, 2009-06-15 at 16:37 +0200, Lennart Poettering wrote:
> On Mon, 15.06.09 15:34, Stéphane Letz (letz@grame.fr) wrote:
>
> >> On Mon, 15.06.09 11:01, Stéphane Letz (letz@grame.fr) wrote:
> >>
> >>>> I was just thinking, when jack2 finished initialization it takes a
> >>>> name on the session bus, right?
> >>>
> >>> Not sure about what you mean by " it takes name on the session bus".
> >>> I hope Nedko can answer better here.
> >>
> >> I simply mean it calls dbus_bus_request_name()
> >> resp. org.freedesktop.DBus.RequestName to acquire a service name n the
> >> session bus, such as org.jack.foo.bar.
> >
> > We recently had a strong debate on JACK dev list about the way DBus
> > could/should be used with JACK.
>
> Yes, I noticed.
>
> > What I'm personally trying to achieve is a more "flexible" way (compared
> > to what is currently a bit hard-coded in JAKC2 SVN) so that a DBus
> > control component can be coded as a "plugin" to be possibly loaded in
> > JACK server process. This new plugin model allows to keep basically 2
> > ways of using JACK server : the "old way" (typically starting the jackd
> > server using Qjackctl control application) or the new way using DBus
> > based control applications (after the DBus control plug-in has been
> > properly loaded in JACK server). (Keeping the "old-way" is also
> > important on others platforms JACK2 runs on.)
>
> Distributions will certainly enable the D-Bus code in JACK if they
> ship it. So, I have no problem with depending on a dbus'ified jack for
> this logic to work.

>From a packagers' (for Fedora/Planet CCRMA) point of view the future
dbus-capable jack should be able to be used without dbus support as well
as with it _without_ having to recompile it (that is without having to
repackage it differently). For an example of non-dbus usage, I may want
to start jack on a remote host where there is no desktop session at the
moment and thus dbus is not usable.

> > If this new "control plugin" model is finally accepted by JACK
> > community, then we'll distribute/package JACK2 compiled with the 1)
> > option, so that it (at least) cooperates with PulseAudio. But 2) would
> > then be optional, so PA can not rely on the DBus control plug-in to
> > always be present.
> >
> > The 1) code uses "org.freedesktop.ReserveDevice1.AudioXX" name, and 2)
> > optional DBus plugin uses "org.jackaudio.service" name. If we want to
> > implement your proposal, the we would need to request another name in 1)
> > part, is that correct?
>
> I think org.jackaudio.service should be fine. I don't think this
> automatic logic needs to work on non-D-Bus jack builds.

I would change the wording to "on jack instances that are not using
dbus" (ie: whether you use dbus or not should not depend on the build).

-- Fernando

> As I see it
> you don't need to make any changes on jack for this to work. All I
> need is the guarantee that by the time the service name is registered
> on the bus jack is fully accessible. Otherwise we had a race here: if
> PA looks for the org.jackaudio.service name to appear on the bus and
> then imemdiately connects to it while jack isn't fully accessible yet
> PA would fail.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 16 00:15:01 2009