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

Brendan Jones brendan.jones.it at gmail.com
Mon Nov 19 12:45:03 PST 2012


On 11/13/2012 08:20 PM, Tanu Kaskinen wrote:
> On Sun, 2012-11-11 at 12:21 -0500, Ian Malone wrote:
>> On 10 November 2012 05:25, Ian Malone <ibmalone at gmail.com> wrote:
>>> On 9 November 2012 17:34, Tanu Kaskinen <tanuk at iki.fi> wrote:
>>>> On Tue, 2012-11-06 at 15:58 -0500, Ian Malone wrote:
>>>>> method call sender=:1.110 ->
>>>>> dest=org.freedesktop.ReserveDevice1.Audio1 serial=6
>>>>> path=/org/freedesktop/ReserveDevice1/Audio1;
>>>>> interface=org.freedesktop.ReserveDevice1; member=RequestRelease
>>>>>     int32 2147483647
>>>>> error sender=:1.35 -> dest=:1.110
>>>>> error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=6
>>>>>     string "Method "RequestRelease" with signature "i" on interface
>>>>> "org.freedesktop.ReserveDevice1" doesn't exist
>>>>> "
>>>>
>>
>>> If I hadn't seen it before I would say that that's exactly the message
>>> I expect a message framework (d-bus here) to generate when the method
>>> wasn't present. And indeed it is:
>>> $  dbus-send --session --print-reply --reply-timeout=2000
>>> --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio1
>>> /org/freedesktop/ReserveDevice1/Audio1
>>> org.freedesktop.ReserveDevice1.RequestRelease int32:5
>>> Error org.freedesktop.DBus.Error.UnknownMethod: Method
>>> "RequestRelease" with signature "i" on interface
>>> "org.freedesktop.ReserveDevice1" doesn't exist
>>>
>>> I don't know how to capture this at the command line, so please see
>>> the d-feet shot of this:
>>>
>>> https://picasaweb.google.com/lh/photo/Mnty0Ul3ilCN_pB-ctJoD9MTjNZETYmyPJy0liipFm0?feat=directlink
>
> Ok, I feel a bit stupid for not taking into account that libdbus or the
> bus daemon or whatever might generate the error message.
>
>>> Audio1 is reserved (the service exists), but the object to request a
>>> release for Audio1 doesn't exist. Getting to this state was actually
>>> quite easy:
>>> 1. Start into KDE (pulse is set up as normal for Fedora and autostarted).
>>> 2. Start d-feet, you may catch the ReserveDevice1 services before they
>>> disappear, but wait till they do.
>>> 3. Open the KDE audio setup dialogue and test playback, this causes
>>> pulse to lock the capture device (hw:0 here) and the playback device
>>> (hw:1).
>>> 4. Look at the 'reserved' services. Audio1 is reserved, but can't be
>>> released because there's no object to provide the method.
>>>
>>
>> =======
>> --- a/src/modules/reserve.c
>> +++ b/src/modules/reserve.c
>> @@ -409,6 +409,11 @@ int rd_acquire(
>>   		goto fail;
>>   	}
>>
>> +	if (k == DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER) {
>> +		// Potential leak?
>> +		goto success;
>> +	}
>> +
>>   	if (k == DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
>>   		goto success;
>> =======
>> It seems rd_acquire can get called while pulse still has the service
>> name (how? don't know. I've tried a return 0 there, but the object
>> path has already been unregistered at that point). Currently that
>> means it unregisters the filter handler and the object path for
>> releasedevice1, turning the service into a zombie until pulse is
>> killed. I've tried fixing this by changing the way d->owning is used,
>> but anything but the current setup seems to get stuck in a loop
>> between rd_callback, the filter_handler in reserve.c and rd_release,
>> possibly because unregistering the service triggers the filter_handler
>> with namelost somehow. Anyway, thou shalt check for possible return
>> values.
>
> Thanks for digging into this. I should really test this myself. I'll try
> to do that tomorrow.
>

Hi

I'm seeing this in virtual box under KDE (also Fedora 18 / pulseaudio 2.1).

On my real desktop, if I configure qjackctl to autostart on logon and in 
turn autostart jack I do not see the problem.

If I stop jack and resume normal desktop use and restart jack after a 
time, the issue does occur.

pulseaudio --kill; pulseaudio --start always fixes the issue.

Is there something I can look out for in the logs, or something I can 
try via pacmd while it is happening to aid in debugging this issue?

We are very close to the release date of the Fedora Audio spin and 
really want to have jack and pulse coexist directly from the install 
media but this issue is holding us back.

Let me know if there is anyway I can help

thanks

Brendan



More information about the pulseaudio-discuss mailing list