On 11/09/2012 12:15 PM, Ian Malone wrote:
On 7 November 2012 08:31, Ian Malone <[email protected]> wrote:
On 7 November 2012 06:46, David Henningsson
<[email protected]> wrote:
On 11/07/2012 12:52 AM, Ian Malone wrote:
On 6 November 2012 15:58, Ian Malone <[email protected]> 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.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
