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

[David Henningsson]

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