Please find below some details from Jack2 dev nedko on the
dbus-specifics, with relation to a recent topic on starting
module-jack-sink/source on surrendering control of the sound card to
Jack.
Patrick Shirkey <pshirkey at boosthardware.com> writes:
> Hi,
>
> I just spotted this on the pa list.
>
>
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-October/005302.html
>
> ==================
>
>> I'm sure the Jack folk know better than I on the D-Bus name,
but
>> jack_control status seems to work fine to tell me when Jack
is ready for
>> use, and it communicates via dbus as well...
>
> Last time I checked they had a name they were picking before
> actually spawning off the jack audio daemon. As long as things
are
> that way round this is not useful for PA's needs.
>
> ==================
>
>
> Can anyone confirm or deny? Seems to be a bit of a blocker to
proper
> dbus integration if PA cannot work with the existing jack2
method for
> registering a name with dbus.
"jack_control status" does not check whether dbus name is owned.
It
checks whether JACK server is started. There are also a D-Bus
signals
that are emited when JACK server starts/stops. D-Bus name is
reserved
when controller is activated and that has nothing to do with
whether
JACK server is started. The controller object is the one who
starts JACK
server. It is a persistent endpoint to control and monitor JACK
server.
So, if pulseaudio needs polling, it can use the
org.jackaudio.JackControl.IsStarted() method.
If it needs notification mechanism, it should subscribe for the
org.jackaudio.JackControl.ServerStarted and
org.jackaudio.JackControl.ServerStopped signals.
