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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
