[pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

[Tanu Kaskinen]

On Fri, 2012-11-09 at 11:15 +0000, Ian Malone wrote:
> Some more data on this, I can actually attach a third audio interface
> to this machine. I've tried that and looked at this with d-feet. Part
> of the behaviour seems to be coupled with what happens when you
> restart pulse. With three devices you can have:
> org.freedesktop.ReserveDevice1.Audio0
> org.freedesktop.ReserveDevice1.Audio1
> org.freedesktop.ReserveDevice1.Audio2.
> 
> I think the first time pulse starts this might look okay (but because
> the services disappear quickly if things are working properly it's
> hard to track). If you restart pulse things definitely go awry. The
> object paths coalesce under one destination. E.g.
> org.freedesktop.ReserveDevice1.Audio2 can end up with all three of
> /org/freedesktop/ReserveDevice1/Audio0,
> /org/freedesktop/ReserveDevice1/Audio1, and
> /org/freedesktop/ReserveDevice1/Audio2. I don't know if that's
> intentional, but what Jack asks for is like
> /org/freedesktop/ReserveDevice1/Audio1 at
> org.freedesktop.ReserveDevice1/Audio1. I've been looking at the code
> in reserve.c to see if I can spot how it can register a path with a
> different address, and haven't found anywhere it's explicitly done, it
> could be something to do with what happens when it requests existing
> names from dbus.

Each of

org.freedesktop.ReserveDevice1.Audio0
org.freedesktop.ReserveDevice1.Audio1
org.freedesktop.ReserveDevice1.Audio2

are bus names that are registered by the same application using the same
D-Bus connection. The object paths are registered per-connection, not
per-bus-name. Therefore, all object paths will be visible through all
bus names. This is expected and shouldn't cause problems.

-- 
Tanu