Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 3 December 2012 04:07, Brendan Jones brendan.jones...@gmail.com 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 ta...@iki.fi wrote: On Wed, 2012-11-21 at 03:04 -0500, Ian Malone wrote: On 20 November 2012 14:01, Tanu Kaskinen ta...@iki.fi 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 Wed, 2012-11-21 at 03:04 -0500, Ian Malone wrote: On 20 November 2012 14:01, Tanu Kaskinen ta...@iki.fi 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 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 20 November 2012 14:01, Tanu Kaskinen ta...@iki.fi 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 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 ibmal...@gmail.com wrote:
On 9 November 2012 17:34, Tanu Kaskinen ta...@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
___
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 ta...@iki.fi
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 20 November 2012 17:37, Tanu Kaskinen ta...@iki.fi 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 17:59 +, Ian Malone wrote: On 20 November 2012 17:37, Tanu Kaskinen ta...@iki.fi 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 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 Sun, 2012-11-11 at 12:21 -0500, Ian Malone wrote:
On 10 November 2012 05:25, Ian Malone ibmal...@gmail.com wrote:
On 9 November 2012 17:34, Tanu Kaskinen ta...@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.
--
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 13 November 2012 19:20, Tanu Kaskinen ta...@iki.fi 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 10 November 2012 05:25, Ian Malone ibmal...@gmail.com wrote:
On 9 November 2012 17:34, Tanu Kaskinen ta...@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
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 ta...@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 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 7 November 2012 08:31, Ian Malone ibmal...@gmail.com wrote: On 7 November 2012 06:46, David Henningsson david.hennings...@canonical.com wrote: On 11/07/2012 12:52 AM, Ian Malone wrote: On 6 November 2012 15:58, Ian Malone ibmal...@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 ___ 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 david.hennings...@canonical.com wrote: On 11/09/2012 12:15 PM, Ian Malone wrote: On 7 November 2012 08:31, Ian Malone ibmal...@gmail.com wrote: On 7 November 2012 06:46, David Henningsson david.hennings...@canonical.com wrote: On 11/07/2012 12:52 AM, Ian Malone wrote: On 6 November 2012 15:58, Ian Malone ibmal...@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. 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 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 7 November 2012 06:46, David Henningsson david.hennings...@canonical.com wrote: On 11/07/2012 12:52 AM, Ian Malone wrote: On 6 November 2012 15:58, Ian Malone ibmal...@gmail.com 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node !-- If you are looking for documentation make sure to check out http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt -- interface name=org.freedesktop.ReserveDevice1 method name=RequestRelease arg name=priority type=i direction=in/ arg name=result type=b direction=out/ /method property name=Priority type=i access=read/ property name=ApplicationName type=s access=read/ property name=ApplicationDeviceName type=s access=read/ /interface interface name=org.freedesktop.DBus.Properties method name=Get arg name=interface direction=in type=s/ arg name=property direction=in type=s/ arg name=value direction=out type=v/ /method /interface interface name=org.freedesktop.DBus.Introspectable method name=Introspect arg name=data type=s direction=out/ /method /interface/node 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node /node 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node !-- If you are looking for documentation make sure to check out http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt -- interface name=org.freedesktop.ReserveDevice1 method name=RequestRelease arg name=priority type=i direction=in/ arg name=result type=b direction=out/ /method property name=Priority type=i access=read/ property name=ApplicationName type=s access=read/ property name=ApplicationDeviceName type=s access=read/ /interface interface name=org.freedesktop.DBus.Properties method name=Get arg name=interface direction=in type=s/ arg name=property direction=in type=s/ arg name=value direction=out type=v/ /method /interface interface name=org.freedesktop.DBus.Introspectable method name=Introspect arg name=data type=s direction=out/ /method /interface/node 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 6 November 2012 11:47, Ian Malone ibmal...@gmail.com wrote: On 5 November 2012 12:49, Ian Malone ibmal...@gmail.com wrote: On 4 November 2012 11:23, Ian Malone ibmal...@gmail.com 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 path=/Mixers/1; interface=org.kde.KMix.Mixer; member=controlChanged
Re: [pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API
On 6 November 2012 15:58, Ian Malone ibmal...@gmail.com 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node !-- If you are looking for documentation make sure to check out http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt -- interface name=org.freedesktop.ReserveDevice1 method name=RequestRelease arg name=priority type=i direction=in/ arg name=result type=b direction=out/ /method property name=Priority type=i access=read/ property name=ApplicationName type=s access=read/ property name=ApplicationDeviceName type=s access=read/ /interface interface name=org.freedesktop.DBus.Properties method name=Get arg name=interface direction=in type=s/ arg name=property direction=in type=s/ arg name=value direction=out type=v/ /method /interface interface name=org.freedesktop.DBus.Introspectable method name=Introspect arg name=data type=s direction=out/ /method /interface/node 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node /node 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 11/07/2012 12:52 AM, Ian Malone wrote: On 6 November 2012 15:58, Ian Malone ibmal...@gmail.com 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node !-- If you are looking for documentation make sure to check out http://git.0pointer.de/?p=reserve.git;a=blob;f=reserve.txt -- interface name=org.freedesktop.ReserveDevice1 method name=RequestRelease arg name=priority type=i direction=in/ arg name=result type=b direction=out/ /method property name=Priority type=i access=read/ property name=ApplicationName type=s access=read/ property name=ApplicationDeviceName type=s access=read/ /interface interface name=org.freedesktop.DBus.Properties method name=Get arg name=interface direction=in type=s/ arg name=property direction=in type=s/ arg name=value direction=out type=v/ /method /interface interface name=org.freedesktop.DBus.Introspectable method name=Introspect arg name=data type=s direction=out/ /method /interface/node 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 !DOCTYPE node PUBLIC -//freedesktop//DTD D-BUS Object Introspection 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd; node /node 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 4 November 2012 11:23, Ian Malone ibmal...@gmail.com 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
