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
