Re: [LAD] jack2's dbus name

PrevNext  Index
DateMon, 15 Jun 2009 16:59:40 +0200
From Stéphane Letz <[hidden] at grame dot fr>
ToLennart Poettering <[hidden] at 0pointer dot de>
CcJack devel <[hidden] at lists dot jackaudio dot org>, Linux Audio Developers <[hidden] at lists dot linuxaudio dot org>
In-Reply-ToLennart Poettering Re: [LAD] jack2's dbus name
>
>> 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.

In the proposed model, having "D-Bus code in JACK" will mean 1)  only  
would be on (reservation code used in ALSA backend). Having a DBus  
control plugin would be optional, that is, it should even probably be  
distributed as a separated package.

> After all crazy folks who disable the dbus support
> in jack because they think it's an abomination probably think that PA
> is an even worse abomination anyway, so there's not need to cater for
> them.

Well me current role as I see it is to try to keep "guardians" and  
"rebels" on the same boat...

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

But this is activated only by the *optional* DBus control plugin..

> I don't think this
> automatic logic needs to work on non-D-Bus jack builds. 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.

This is not the case right now. The org.jackaudio.service is started  
and then DBus control application can access it, to configure, start/ 
stop the server... This mean that the JACK server is not always started.

So I guess we'll have to implement something new in the 1) part, since  
I guess we want this JACK/PA cooperation, even if users are not using  
DBus based control applications to control JACK.

Stephane
PrevNext  Index

1245078232.4976_0.ltw:2,a <CF486BAB-03E8-4EE6-A32E-99D9EA83FB67 at grame dot fr>