On 11/09/2012 12:15 PM, Ian Malone wrote: > On 7 November 2012 08:31, Ian Malone <ibmalone at gmail.com> wrote: >> On 7 November 2012 06:46, David Henningsson >> <david.henningsson at canonical.com> wrote: >>> On 11/07/2012 12:52 AM, Ian Malone wrote: >>>> >>>> On 6 November 2012 15:58, Ian Malone <ibmalone at gmail.com> wrote: > >>>>> I'll speculate that something somewhere is confused by the presence of >>>>> two devices and either Audio1 isn't being provided correctly by pulse >>>>> (though it does create it) or requested properly by Jack (though with >>>>> only one parameter that's difficult to believe). >>>>> >>>> >>>> I now know enough about dbus to confirm this, the second interface is >>>> not created properly for some reason. >>>> > >>> >>> Hi, >>> >>> FWIW, I tried to reproduce this last evening under Ubuntu 12.10 (which uses >>> PulseAudio 2.1), but it seems to create properly interfaces for the two card >>> scenario here. I used the "d-feet" introspect program to verify. >>> (Jackd2-dbus seemed to crash on startup for some reason I have not tracked >>> down.) >>> >>> >> >> Thanks for trying. I've had a look at d-feet and noticed that >> org.freedesktop.ReserveDevice1.Audio0 and >> org.freedesktop.ReserveDevice1.Audio1 both look okay,ReserveDevice1 is >> there. EXCEPT that the object path for both is >> org.freedesktop.ReserveDevice1.Audio0. In other words, N.B. different >> dest and path: >> >> $ dbus-send --session --print-reply --reply-timeout=2000 >> --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio1 >> /org/freedesktop/ReserveDevice1/Audio0 >> org.freedesktop.DBus.Introspectable.Introspect >> > <introspection information returned here> > > >> I don't know very much about dbus, but I haven't seen that before. The >> is pulseaudio-2.1-4.fc18.x86_64, but from the dates in git I don't >> think the dbus code has been touched in a while. >> > > 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/Audio1at > 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. > For the record, what version of PulseAudio are you running, and in particular, do you have the pa_assert_se(dbus_threads_init_default()) call present in main.c? It seems d-bus can do crazy things if this one is missing. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
