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

[Tanu Kaskinen]

On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote:
> 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

I can reproduce some weird behavior which I've been investigating, but
right now there's a bluetooth bug that is at a higher priority. I think
I can finish that today, though, so I can continue with this device
reservation stuff right after that.

I don't think I need more debug information right now - let's see if
fixing the bugs that I'm seeing also fixes your issues.

-- 
Tanu