> >> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
