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

[Ian Malone]

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.

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