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

[Ian Malone]

On 9 November 2012 13:59, David Henningsson
<david.henningsson at canonical.com> wrote:
> 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.
>

pulseaudio-2.1-4.fc18.x86_64, uses pulseaudio-2.1 source, has
pa_assert_se(dbus_threads_init_default())
at line 1069 in a #ifdef HAVE_DBUS
(would cut and paste, but typing from another computer)

I did try capturing dbus-monitor while restarting pulseaudio, but
doesn't seem to have anything useful (specifically no object paths
appear, which is what I think I'm trying to find).

-- 
imalone
http://ibmalone.blogspot.co.uk