Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 01/14/2013 02:44 AM, Ian Malone wrote: On 3 December 2012 04:07, Brendan Jones wrote: On 12/02/2012 11:42 PM, Tanu Kaskinen wrote: Thanks, I'm now able to reproduce the bug. I will try to find the root cause. Thanks Tanu! Let me know what we can do to help. Fedora is a release behind you guys for F18 (we will not be ugrading to 2.99 until F19 I believe), but Rex Dieter should not have too many problems with backporting bug fixes into 2.1. He also provides a repo for those wanting to try the latest pulseaudio but he hasn't updated it to 2.99 for F18. I will endeavour to take on a bigger role in diagnosing pulseaudio bugs with you guys from here on. This single commit, between 2.99.1 and 2.99.2 seems to be what prevents the problem in for this case. Applying it to Fedora's 2.1 package also fixes the problem, I guess the rate change may be one of the cases that causes the self-request to happen. http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=cd1102cce01e47645ed03ddf46a0a8b80d65fc9e We could ask Rex to apply it in Fedora as a backport, but I suspect it only avoids triggering the bug and is not the bug itself. I can confirm that it works, but I'd lying if I said I understood why. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 3 December 2012 04:07, Brendan Jones wrote: > On 12/02/2012 11:42 PM, Tanu Kaskinen wrote: >> >> Thanks, I'm now able to reproduce the bug. I will try to find the root >> cause. >> > Thanks Tanu! Let me know what we can do to help. Fedora is a release behind > you guys for F18 (we will not be ugrading to 2.99 until F19 I believe), but > Rex Dieter should not have too many problems with backporting bug fixes into > 2.1. He also provides a repo for those wanting to try the latest pulseaudio > but he hasn't updated it to 2.99 for F18. I will endeavour to take on a > bigger role in diagnosing pulseaudio bugs with you guys from here on. This single commit, between 2.99.1 and 2.99.2 seems to be what prevents the problem in for this case. Applying it to Fedora's 2.1 package also fixes the problem, I guess the rate change may be one of the cases that causes the self-request to happen. http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=cd1102cce01e47645ed03ddf46a0a8b80d65fc9e We could ask Rex to apply it in Fedora as a backport, but I suspect it only avoids triggering the bug and is not the bug itself. -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 12/02/2012 11:42 PM, Tanu Kaskinen wrote: On Wed, 2012-11-28 at 23:24 +0100, Brendan Jones wrote: On 11/24/2012 02:06 PM, Tanu Kaskinen wrote: On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote: I'm seeing this in virtual box under KDE (also Fedora 18 / pulseaudio 2.1). I guess it should be quite easy to reproduce this if I'd try this with virtual box with the same setup as you. I've never used virtual box (or any other virtual machine), but I think I should learn to do that. After installing virtual box, I guess I need some OS image - could you point me to the one that you were using when you reproduced this? Thanks for following up. I also tried your patch with the same results. You can try the latest Fedora 18 Beta. I've been using the Live KDE spin. http://fedoraproject.org/get-prerelease You can tab to get to the live kernel boot parameters and add a 3 to get to init 3 equivalent. From there you can edit the /usr/bin/start-pulseaudio-kde script to add log in and install packages into the live image as you require, e.g. su -c 'yum install jack-audio-connection-kit-dbus d-feet pulseaudio-debuginfo qjackctl' Followed by init 5 to get X under liveuser Thanks, I'm now able to reproduce the bug. I will try to find the root cause. Thanks Tanu! Let me know what we can do to help. Fedora is a release behind you guys for F18 (we will not be ugrading to 2.99 until F19 I believe), but Rex Dieter should not have too many problems with backporting bug fixes into 2.1. He also provides a repo for those wanting to try the latest pulseaudio but he hasn't updated it to 2.99 for F18. I will endeavour to take on a bigger role in diagnosing pulseaudio bugs with you guys from here on. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Wed, 2012-11-28 at 23:24 +0100, Brendan Jones wrote: > On 11/24/2012 02:06 PM, Tanu Kaskinen wrote: > > On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote: > >> I'm seeing this in virtual box under KDE (also Fedora 18 / pulseaudio 2.1). > > > > I guess it should be quite easy to reproduce this if I'd try this with > > virtual box with the same setup as you. I've never used virtual box (or > > any other virtual machine), but I think I should learn to do that. After > > installing virtual box, I guess I need some OS image - could you point > > me to the one that you were using when you reproduced this? > > > Thanks for following up. I also tried your patch with the same results. > > You can try the latest Fedora 18 Beta. I've been using the Live KDE spin. > > http://fedoraproject.org/get-prerelease > > You can tab to get to the live kernel boot parameters and add a 3 to get > to init 3 equivalent. > > From there you can edit the /usr/bin/start-pulseaudio-kde script to add > log in and install packages into the live image as you require, e.g. > > su -c 'yum install jack-audio-connection-kit-dbus d-feet > pulseaudio-debuginfo qjackctl' > > Followed by init 5 to get X under liveuser Thanks, I'm now able to reproduce the bug. I will try to find the root cause. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 24 November 2012 13:01, Tanu Kaskinen wrote: > On Wed, 2012-11-21 at 03:04 -0500, Ian Malone wrote: >> On 20 November 2012 14:01, Tanu Kaskinen wrote: >> > On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote: >> >> On Tue, 2012-11-20 at 17:59 +, Ian Malone wrote: >> >> > Thanks, I'll give it a go. I think handling the already_owner case in >> >> > reserve.c as well might be worthwhile since there may be other ways to >> >> > get to that state. >> >> >> >> I think it's a bug in the application if it calls rd_acquire for a >> >> device that it already owns. An assertion might be the way to go. If not >> >> an assertion, then at least an error. >> > >> > When writing that, I didn't realize that the current code already >> > returns an error if dbus_bus_request_name() returns >> > DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of >> > handling it, so in my opinion nothing needs to be done here. >> > >> >> Okay I agree there is probably a more serious bug somewhere. I'll just >> point out that the current response does not result in an error in >> verbose output and that encountering that response results in removing >> the reserve method and handlers, meaning if the service isn't broken >> before it happens then it certainly is afterwards. > > Yes, if that error happens, the device reservation won't work, but the > problem is not that the error is handled badly, the problem is that the > error happens. > That's probably not very useful when debugging this bug, though. When > debugging this, I'd like you to add this assertion to rd_acquire(): > > assert(k != DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER); > > Then run pulseaudio in gdb and get a backtrace. Also, would it be > possible for you try 2.99.2 (with the patch for reserve.c added)? > I'm attaching the backtrace for 2.1, without the reserve.c patch added as otherwise it doesn't hit that condition. 2.99 with the reserve.c patch appears to work in that it drops the DBus service correctly and the test playback from the KDE Audio Setup works. 2.1 on the same setup does not release the device without the reserve.c patch and with the reserve.c patch it drops the DBus service but does not play the test sonud from audio setup. -- imalone http://ibmalone.blogspot.co.uk pulse-2.1-nocbpatch-assert.bt Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 24 November 2012 13:01, Tanu Kaskinen wrote: > Note that you can add another "v" to get even more verbose output. I'm > not sure what I should look for in those logs. You said that "playback Neither am I, but then I'm not a developer for this project. > doesn't work" - is that a good or a bad thing? Usually it's a bad thing, > but is the playback supposed to not work in this case due to the device > reservation? It looks like the alsa sink doesn't get unsuspended when > the last stream is created, so it looks like the device reservation is > doing its job (partially). Given that it's pulse reserving the device lack of playback is not a feature. Right, will run it again with 2.99.2. Assuming I can get it built and packaged. -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote: > I'm seeing this in virtual box under KDE (also Fedora 18 / pulseaudio 2.1). I guess it should be quite easy to reproduce this if I'd try this with virtual box with the same setup as you. I've never used virtual box (or any other virtual machine), but I think I should learn to do that. After installing virtual box, I guess I need some OS image - could you point me to the one that you were using when you reproduced this? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Wed, 2012-11-21 at 03:04 -0500, Ian Malone wrote:
> On 20 November 2012 14:01, Tanu Kaskinen wrote:
> > On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote:
> >> On Tue, 2012-11-20 at 17:59 +, Ian Malone wrote:
> >> > Thanks, I'll give it a go. I think handling the already_owner case in
> >> > reserve.c as well might be worthwhile since there may be other ways to
> >> > get to that state.
> >>
> >> I think it's a bug in the application if it calls rd_acquire for a
> >> device that it already owns. An assertion might be the way to go. If not
> >> an assertion, then at least an error.
> >
> > When writing that, I didn't realize that the current code already
> > returns an error if dbus_bus_request_name() returns
> > DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of
> > handling it, so in my opinion nothing needs to be done here.
> >
>
> Okay I agree there is probably a more serious bug somewhere. I'll just
> point out that the current response does not result in an error in
> verbose output and that encountering that response results in removing
> the reserve method and handlers, meaning if the service isn't broken
> before it happens then it certainly is afterwards.
Yes, if that error happens, the device reservation won't work, but the
problem is not that the error is handled badly, the problem is that the
error happens.
Btw, error from rd_acquire() does cause a log message to be printed in
reserve-wrap.c:
pa_log_debug("Failed to acquire reservation lock on device '%s': %s",
device_name, pa_cstrerror(-k));
That's probably not very useful when debugging this bug, though. When
debugging this, I'd like you to add this assertion to rd_acquire():
assert(k != DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER);
Then run pulseaudio in gdb and get a backtrace. Also, would it be
possible for you try 2.99.2 (with the patch for reserve.c added)?
> Moving on: 0001-reserve-Call-change_cb-only-if-there-actually-was-a-.patch
> I think we might be getting somewhere. This doesn't actually fix the
> problem, the service without a reservedevice1/audioN method still gets
> produced (this is the use case of trying KDE audio properties), but
> playback doesn't work, so it may be doing something related to the
> problem:
>
> pulseaudio -v output, no patch: http://pastebin.com/yfGEu1qx
> pulseaudio -v output, patched: http://pastebin.com/HkjSST4p
Note that you can add another "v" to get even more verbose output. I'm
not sure what I should look for in those logs. You said that "playback
doesn't work" - is that a good or a bad thing? Usually it's a bad thing,
but is the playback supposed to not work in this case due to the device
reservation? It looks like the alsa sink doesn't get unsuspended when
the last stream is created, so it looks like the device reservation is
doing its job (partially).
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 20 November 2012 14:01, Tanu Kaskinen wrote: > On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote: >> On Tue, 2012-11-20 at 17:59 +, Ian Malone wrote: >> > Thanks, I'll give it a go. I think handling the already_owner case in >> > reserve.c as well might be worthwhile since there may be other ways to >> > get to that state. >> >> I think it's a bug in the application if it calls rd_acquire for a >> device that it already owns. An assertion might be the way to go. If not >> an assertion, then at least an error. > > When writing that, I didn't realize that the current code already > returns an error if dbus_bus_request_name() returns > DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of > handling it, so in my opinion nothing needs to be done here. > Okay I agree there is probably a more serious bug somewhere. I'll just point out that the current response does not result in an error in verbose output and that encountering that response results in removing the reserve method and handlers, meaning if the service isn't broken before it happens then it certainly is afterwards. Moving on: 0001-reserve-Call-change_cb-only-if-there-actually-was-a-.patch I think we might be getting somewhere. This doesn't actually fix the problem, the service without a reservedevice1/audioN method still gets produced (this is the use case of trying KDE audio properties), but playback doesn't work, so it may be doing something related to the problem: pulseaudio -v output, no patch: http://pastebin.com/yfGEu1qx pulseaudio -v output, patched: http://pastebin.com/HkjSST4p -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote: > On Tue, 2012-11-20 at 17:59 +, Ian Malone wrote: > > Thanks, I'll give it a go. I think handling the already_owner case in > > reserve.c as well might be worthwhile since there may be other ways to > > get to that state. > > I think it's a bug in the application if it calls rd_acquire for a > device that it already owns. An assertion might be the way to go. If not > an assertion, then at least an error. When writing that, I didn't realize that the current code already returns an error if dbus_bus_request_name() returns DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of handling it, so in my opinion nothing needs to be done here. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Tue, 2012-11-20 at 17:59 +, Ian Malone wrote: > On 20 November 2012 17:37, Tanu Kaskinen wrote: > > On Tue, 2012-11-20 at 12:45 +0200, Tanu Kaskinen wrote: > >> On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote: > >> > 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. > > > > I've attached a patch that fixes the bug that I've been investigating. > > The fix ended up being very simple, but I think it's quite unlikely that > > it will fix your problem. If you could try the patch, that would be > > great. In the mean time, I'll try to reproduce the bug that you're > > seeing. > > > > Thanks, I'll give it a go. I think handling the already_owner case in > reserve.c as well might be worthwhile since there may be other ways to > get to that state. I think it's a bug in the application if it calls rd_acquire for a device that it already owns. An assertion might be the way to go. If not an assertion, then at least an error. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 20 November 2012 17:37, Tanu Kaskinen wrote: > On Tue, 2012-11-20 at 12:45 +0200, Tanu Kaskinen wrote: >> On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote: >> > 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. > > I've attached a patch that fixes the bug that I've been investigating. > The fix ended up being very simple, but I think it's quite unlikely that > it will fix your problem. If you could try the patch, that would be > great. In the mean time, I'll try to reproduce the bug that you're > seeing. > Thanks, I'll give it a go. I think handling the already_owner case in reserve.c as well might be worthwhile since there may be other ways to get to that state. -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Tue, 2012-11-20 at 12:45 +0200, Tanu Kaskinen wrote:
> On Mon, 2012-11-19 at 21:45 +0100, Brendan Jones wrote:
> > 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.
I've attached a patch that fixes the bug that I've been investigating.
The fix ended up being very simple, but I think it's quite unlikely that
it will fix your problem. If you could try the patch, that would be
great. In the mean time, I'll try to reproduce the bug that you're
seeing.
--
Tanu
>From 179e96dd5bb49dfb14da1db59debe79231f5101d Mon Sep 17 00:00:00 2001
From: Tanu Kaskinen
Date: Tue, 20 Nov 2012 18:26:42 +0200
Subject: [PATCH] reserve: Call change_cb() only if there actually was a
change.
---
src/modules/reserve-monitor.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/modules/reserve-monitor.c b/src/modules/reserve-monitor.c
index ab453e6..4097a6f 100644
--- a/src/modules/reserve-monitor.c
+++ b/src/modules/reserve-monitor.c
@@ -85,6 +85,8 @@ static DBusHandlerResult filter_handler(
goto invalid;
if (strcmp(name, m->service_name) == 0) {
+ unsigned old_busy = m->busy;
+
m->busy = !!(new && *new);
/* If we ourselves own the device, then don't consider this 'busy' */
@@ -96,7 +98,7 @@ static DBusHandlerResult filter_handler(
m->busy = FALSE;
}
- if (m->change_cb) {
+ if (m->busy != old_busy && m->change_cb) {
m->ref++;
m->change_cb(m);
rm_release(m);
--
1.7.10.4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
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 wrote:
> >>> On 9 November 2012 17:34, Tanu Kaskinen 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
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
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 wrote:
On 9 November 2012 17:34, Tanu Kaskinen 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
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 13 November 2012 19:20, Tanu Kaskinen wrote: > On Sun, 2012-11-11 at 12:21 -0500, Ian Malone wrote: >> 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. > Cool, thanks. If it's any help in reproducing it: I can get to this state quite easily with a single device available (in a VM) and using the test playback button in KDE's audio setup dialogue (using gstreamer->pulse backend). If quick after login or a pulseaudio -k I can see the services being created and disappearing normally, so it may be something to do with interaction with one of those. There's a suspend event during that process, I can post some - outputs from it if it's any help (with some logging added to reserve.c too). -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Sun, 2012-11-11 at 12:21 -0500, Ian Malone wrote:
> On 10 November 2012 05:25, Ian Malone wrote:
> > On 9 November 2012 17:34, Tanu Kaskinen 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.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 10 November 2012 05:25, Ian Malone wrote:
> On 9 November 2012 17:34, Tanu Kaskinen 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
>
> 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.
--
imalone
http://ibmalone.blogspot.co.uk
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 9 November 2012 17:34, Tanu Kaskinen 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 >> " > > As far as I know, that error message is generated by the application > that responds to the RequestRelease method call. PulseAudio doesn't have > code that would generate an error message like that, so it looks like > it's actually something else that is sending the error. Here the error > sender is :1.35, which is not very useful, but if you get the > dbus-monitor log again, you can check with d-feet what application is > returning that error (in this case you'd check which application > is :1.35, but that number will probably be different when you try > again). > 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 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. -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On Fri, 2012-11-09 at 11:15 +, Ian Malone wrote: > 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/Audio1 at > 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. Each of org.freedesktop.ReserveDevice1.Audio0 org.freedesktop.ReserveDevice1.Audio1 org.freedesktop.ReserveDevice1.Audio2 are bus names that are registered by the same application using the same D-Bus connection. The object paths are registered per-connection, not per-bus-name. Therefore, all object paths will be visible through all bus names. This is expected and shouldn't cause problems. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
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 > " As far as I know, that error message is generated by the application that responds to the RequestRelease method call. PulseAudio doesn't have code that would generate an error message like that, so it looks like it's actually something else that is sending the error. Here the error sender is :1.35, which is not very useful, but if you get the dbus-monitor log again, you can check with d-feet what application is returning that error (in this case you'd check which application is :1.35, but that number will probably be different when you try again). -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 9 November 2012 13:59, David Henningsson wrote: > On 11/09/2012 12:15 PM, Ian Malone wrote: >> >> On 7 November 2012 08:31, Ian Malone wrote: >>> >>> On 7 November 2012 06:46, David Henningsson >>> wrote: On 11/07/2012 12:52 AM, Ian Malone wrote: > > > On 6 November 2012 15:58, Ian Malone 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 >>> >> >> >> >>> 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 11/09/2012 12:15 PM, Ian Malone wrote: On 7 November 2012 08:31, Ian Malone wrote: On 7 November 2012 06:46, David Henningsson wrote: On 11/07/2012 12:52 AM, Ian Malone wrote: On 6 November 2012 15:58, Ian Malone 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 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. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 7 November 2012 08:31, Ian Malone wrote: > On 7 November 2012 06:46, David Henningsson > wrote: >> On 11/07/2012 12:52 AM, Ian Malone wrote: >>> >>> On 6 November 2012 15:58, Ian Malone 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 > > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 7 November 2012 06:46, David Henningsson wrote: > On 11/07/2012 12:52 AM, Ian Malone wrote: >> >> On 6 November 2012 15:58, Ian Malone wrote: >> etc. >> >> >>> >>> 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. >> >> Here's Audio0: >> [liveuser@localhost ~]$ dbus-send --session --print-reply >> --reply-timeout=2000 --type=method_call >> --dest=org.freedesktop.ReserveDevice1.Audio0 >> /org/freedesktop/ReserveDevice1/Audio0 >> org.freedesktop.DBus.Introspectable.Introspect >> method return sender=:1.119 -> dest=:1.154 reply_serial=2 >> string "> Introspection 1.0//EN" >> "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> >> >> > name="RequestRelease"> > direction="in"/> >> >> > name="ApplicationDeviceName" type="s" access="read"/> >> > name="Get"> > name="property" direction="in" type="s"/> > direction="out" type="v"/>> name="org.freedesktop.DBus.Introspectable"> > name="Introspect"> >> " >> >> Here's Audio1: >> [liveuser@localhost ~]$ dbus-send --session --print-reply >> --reply-timeout=2000 --type=method_call >> --dest=org.freedesktop.ReserveDevice1.Audio1 >> /org/freedesktop/ReserveDevice1/Audio1 >> org.freedesktop.DBus.Introspectable.Introspect >> method return sender=:1.119 -> dest=:1.155 reply_serial=2 >> string "> Introspection 1.0//EN" >> "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> >> >> >> " >> >> At this point I don't think I have any doubt there's a bug in the >> pulse dbus handling. > > > 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 method return sender=:1.35 -> dest=:1.113 reply_serial=2 string "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> " 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. -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 11/07/2012 12:52 AM, Ian Malone wrote: On 6 November 2012 15:58, Ian Malone wrote: etc. 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. Here's Audio0: [liveuser@localhost ~]$ dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio0 /org/freedesktop/ReserveDevice1/Audio0 org.freedesktop.DBus.Introspectable.Introspect method return sender=:1.119 -> dest=:1.154 reply_serial=2 string "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> " Here's Audio1: [liveuser@localhost ~]$ dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio1 /org/freedesktop/ReserveDevice1/Audio1 org.freedesktop.DBus.Introspectable.Introspect method return sender=:1.119 -> dest=:1.155 reply_serial=2 string "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> " At this point I don't think I have any doubt there's a bug in the pulse dbus handling. 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.) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 6 November 2012 15:58, Ian Malone wrote: etc. > > 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. Here's Audio0: [liveuser@localhost ~]$ dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio0 /org/freedesktop/ReserveDevice1/Audio0 org.freedesktop.DBus.Introspectable.Introspect method return sender=:1.119 -> dest=:1.154 reply_serial=2 string "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> " Here's Audio1: [liveuser@localhost ~]$ dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio1 /org/freedesktop/ReserveDevice1/Audio1 org.freedesktop.DBus.Introspectable.Introspect method return sender=:1.119 -> dest=:1.155 reply_serial=2 string "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> " At this point I don't think I have any doubt there's a bug in the pulse dbus handling. -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 6 November 2012 11:47, Ian Malone wrote: > On 5 November 2012 12:49, Ian Malone wrote: >> On 4 November 2012 11:23, Ian Malone wrote: >>> Hi, >>> >>> I'm trying to get a Jack DBUS setup working on Fedora 18. It seems >>> pulse refuses to release the audio device when it gets a dbus request >>> from jack: >>> >>> Sat Nov 3 20:08:11 2012: [1m [31mERROR: Failed to acquire device >>> name : Audio1 error : Method "RequestRelease" with signature "i" on >>> interface "org.freedesktop.ReserveDevice1" doesn't exist >>> [0m >>> Sat Nov 3 20:08:11 2012: [1m [31mERROR: Audio device hw:1 cannot be >>> acquired... [0m > >>> If pulse is running but doesn't have the device then jack starts okay >>> and the sink/source modules get loaded. > Sorry if I'm boring people with this. The magic recipe to get a list of available interfaces (or whatever they're called in dbus speak) is: dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames $ dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames|grep org.freedesktop.ReserveDevice1 string "org.freedesktop.ReserveDevice1.Audio0" string "org.freedesktop.ReserveDevice1.Audio1" While simultaneously: Acquire audio card Audio0 Failed to acquire device name : Audio1 error : Method "RequestRelease" with signature "i" on interface "org.freedesktop.ReserveDevice1" doesn't exist dbus-monitor of this neogtiation while trying to start jackdbus via jack_control: method call sender=:1.97 -> dest=:1.82 serial=4 path=/org/jackaudio/Controller; interface=org.jackaudio.JackControl; member=StartServer method call sender=:1.82 -> dest=org.freedesktop.DBus serial=18 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.freedesktop.ReserveDevice1.Audio0" uint32 4 method call sender=:1.82 -> dest=org.freedesktop.ReserveDevice1.Audio0 serial=19 path=/org/freedesktop/ReserveDevice1/Audio0; interface=org.freedesktop.ReserveDevice1; member=RequestRelease int32 2147483647 signal sender=org.freedesktop.DBus -> dest=(null destination) serial=222 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.freedesktop.ReserveDevice1.Audio0" string ":1.35" string "" method call sender=:1.35 -> dest=org.freedesktop.DBus serial=36 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName string "org.freedesktop.ReserveDevice1.Audio0" method return sender=:1.35 -> dest=:1.82 reply_serial=19 boolean true signal sender=org.freedesktop.DBus -> dest=(null destination) serial=59 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.freedesktop.ReserveDevice1.Audio0" string "" string ":1.35" method call sender=:1.35 -> dest=org.freedesktop.DBus serial=38 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.freedesktop.ReserveDevice1.Audio0" uint32 5 signal sender=org.freedesktop.DBus -> dest=(null destination) serial=223 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.freedesktop.ReserveDevice1.Audio0" string ":1.35" string ":1.82" method call sender=:1.82 -> dest=org.freedesktop.DBus serial=20 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.freedesktop.ReserveDevice1.Audio0" uint32 6 signal sender=org.freedesktop.DBus -> dest=(null destination) serial=63 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.freedesktop.ReserveDevice1.Audio0" string ":1.82" string "" method call sender=:1.82 -> dest=org.freedesktop.DBus serial=21 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName string "org.freedesktop.ReserveDevice1.Audio0" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=64 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.freedesktop.ReserveDevice1.Audio0" string "" string ":1.35" method call sender=:1.35 -> dest=org.freedesktop.DBus serial=39 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.freedesktop.ReserveDevice1.Audio0" uint32 5 signal sender=:1.2 -> dest=(null destination) serial=1713 path=/Mixers/1; interface=org.kde.KMix.Mixer; member=controlChanged signal sender=:1.29 -> dest=(null destination) serial=78 path=/Mixers/1; interface=org.kde.KMix.Mixer; member=controlChanged signal sender=:1.2 -> dest=(null destination) serial=1714 path=/Mixers/1; interface=org.kde.KMix.Mixer; member=controlChanged signal sender=:1.2 -> dest=(null destination) serial=1715 path=/Mixers/1; interface=org.kde.KMix.Mixer; member=controlChanged signal sender=:1.29 -> dest=(null destination) serial=79
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 5 November 2012 12:49, Ian Malone wrote: > On 4 November 2012 11:23, Ian Malone wrote: >> Hi, >> >> I'm trying to get a Jack DBUS setup working on Fedora 18. It seems >> pulse refuses to release the audio device when it gets a dbus request >> from jack: >> >> Sat Nov 3 20:08:11 2012: [1m [31mERROR: Failed to acquire device >> name : Audio1 error : Method "RequestRelease" with signature "i" on >> interface "org.freedesktop.ReserveDevice1" doesn't exist >> [0m >> Sat Nov 3 20:08:11 2012: [1m [31mERROR: Audio device hw:1 cannot be >> acquired... [0m >> If pulse is running but doesn't have the device then jack starts okay >> and the sink/source modules get loaded. > Some further information from one of Fedora's pulse co-maintainers > Brendan Jones: >> It seems that the module-esound-protocol is loaded be default. It takes a >> lock >> on the device (see ls /tmp.esd*) which seems to stop it from allowing pusle >> to >> release the device. > > I haven't had time to check this yet, but even if it's true the > message 'Method "RequestRelease" with signature "i" on interface > "org.freedesktop.ReserveDevice1" doesn't exist' seems to suggest that > the dbus interface is not working properly anyway. Having checked I now think that's correct: the esound module may have issues and cause the lock to be held longer than normal, but not loading it does not solve the problem. The core issue is that pulse is not responding to '"RequestRelease" with signature "i"'. I've had a dig around in src/modules/reserve.c and can't see anything obviously wrong there. It's included by the alsa-card module. If anyone can offer information on how to investigate this further, for example dbus introspection to try or how to test dbus method requests to pulse, it would be appreciated. At the moment for our music creation spin (Fedora Jam) I can only recommend we disable pulse because a working Jack setup is more important. Thanks, -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 4 November 2012 11:23, Ian Malone wrote: > Hi, > > I'm trying to get a Jack DBUS setup working on Fedora 18. It seems > pulse refuses to release the audio device when it gets a dbus request > from jack: > > Sat Nov 3 20:08:11 2012: Starting jack server... > Sat Nov 3 20:08:11 2012: JACK server starting in realtime mode with priority > 60 > Sat Nov 3 20:08:11 2012: control device hw:1 > Sat Nov 3 20:08:11 2012: control device hw:1 > Sat Nov 3 20:08:11 2012: [1m [31mERROR: Failed to acquire device > name : Audio1 error : Method "RequestRelease" with signature "i" on > interface "org.freedesktop.ReserveDevice1" doesn't exist > [0m > Sat Nov 3 20:08:11 2012: [1m [31mERROR: Audio device hw:1 cannot be > acquired... [0m > Sat Nov 3 20:08:11 2012: [1m [31mERROR: Cannot initialize driver [0m > Sat Nov 3 20:08:11 2012: [1m [31mERROR: JackServer::Open() failed with -1 > [0m > Sat Nov 3 20:08:11 2012: [1m [31mERROR: Failed to open server [0m > > If pulse is running but doesn't have the device then jack starts okay > and the sink/source modules get loaded. So this is just a failure in > negotiating the release. > > I'm told this is a problem with pulse's implementation of the > interface. The only reference I can find is this: > http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt > > Can anyone provide any insight on this issue please? > Some further information from one of Fedora's pulse co-maintainers Brendan Jones: https://bugzilla.redhat.com/show_bug.cgi?id=872362#c9 > It seems that the module-esound-protocol is loaded be default. It takes a lock > on the device (see ls /tmp.esd*) which seems to stop it from allowing pusle to > release the device. I haven't had time to check this yet, but even if it's true the message 'Method "RequestRelease" with signature "i" on interface "org.freedesktop.ReserveDevice1" doesn't exist' seems to suggest that the dbus interface is not working properly anyway. I've noticed that it pulse is active but hasn't been used for playback then Jack can claim the device okay, so possibly this locking issue is only acting to make that failure to respond to the request visible? -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
Hi, I'm trying to get a Jack DBUS setup working on Fedora 18. It seems pulse refuses to release the audio device when it gets a dbus request from jack: Sat Nov 3 20:08:11 2012: Starting jack server... Sat Nov 3 20:08:11 2012: JACK server starting in realtime mode with priority 60 Sat Nov 3 20:08:11 2012: control device hw:1 Sat Nov 3 20:08:11 2012: control device hw:1 Sat Nov 3 20:08:11 2012: [1m [31mERROR: Failed to acquire device name : Audio1 error : Method "RequestRelease" with signature "i" on interface "org.freedesktop.ReserveDevice1" doesn't exist [0m Sat Nov 3 20:08:11 2012: [1m [31mERROR: Audio device hw:1 cannot be acquired... [0m Sat Nov 3 20:08:11 2012: [1m [31mERROR: Cannot initialize driver [0m Sat Nov 3 20:08:11 2012: [1m [31mERROR: JackServer::Open() failed with -1 [0m Sat Nov 3 20:08:11 2012: [1m [31mERROR: Failed to open server [0m If pulse is running but doesn't have the device then jack starts okay and the sink/source modules get loaded. So this is just a failure in negotiating the release. I'm told this is a problem with pulse's implementation of the interface. The only reference I can find is this: http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt Can anyone provide any insight on this issue please? -- imalone http://ibmalone.blogspot.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
