On Mon, 15.06.09 15:34, Stéphane Letz ([email protected]) wrote: >> On Mon, 15.06.09 11:01, Stéphane Letz ([email protected]) 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. 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. > 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. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
