15 Jun
2009
15 Jun
'09
3:16 p.m.
On Mon, 2009-06-15 at 16:37 +0200, Lennart Poettering wrote:
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
On Mon, 15.06.09 15:34, Stéphane Letz (letz(a)grame.fr)
wrote:
Yes, I noticed.
On Mon,
15.06.09 11:01, Stéphane Letz (letz(a)grame.fr) wrote:
We recently had a strong debate on JACK dev list about the way DBus
could/should be used with JACK. > 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. 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. 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.