So, you managed to connect your phone right? Because as I said my
PulseAudio completely freezes when trying to load bluez5-device-module.
Thanks.
*From:*pulseaudio-discuss
[mailto:[email protected]] *On Behalf
Of *Georg Chini
*Sent:* Sunday, August 16, 2015 4:07 PM
*To:* General PulseAudio Discussion
*Subject:* Re: [pulseaudio-discuss] pulseaudio a2dp disconnect problem
On 16.08.2015 13:40, Georg Chini wrote:
On 16.08.2015 13:26, Eytan Naim wrote:
Hi Georg,
It is asymmetric and I will explain.
When a2dp connection is established, loopback_module is
loaded- And that is before streaming has started, so streaming
is in IDLE state.
Later, when remote device pauses the streaming for small
interval, it keeps the connection up, and I would expect
PulseAudio state machine would go back to an IDLE state-
without removal of loppback_module.
Thanks.
*From:*pulseaudio-discuss
[mailto:[email protected]] *On
Behalf Of *Georg Chini
*Sent:* Sunday, August 16, 2015 2:02 PM
*To:* General PulseAudio Discussion
*Subject:* Re: [pulseaudio-discuss] pulseaudio a2dp disconnect
problem
On 16.08.2015 12:26, Eytan Naim wrote:
Hi Tanu,
Thanks for your advice and cooperation.
As a result of the loopback_module asymmetric oddity, I
compared "pacmd list" output command between two states
(you can see attached files):
1.After connection establishment, and before streaming starts.
2.After streaming stops.
If the application would run normally I would expect to
find similar output. – but for some reason the Bluetooth
card change its active_profile from a2dp_sink to off, so,
I assumed this may be the problem.
So after digging a little bit in the code, I found a
condition in the
./src/modules/bluetooth/module-bluetooth-policy.c that
include all profiles except mine(a2dp source).
So I decided to apply the following hunk, to prevent the
card changing its profile (it seemed reasonable for me,
because all other profile are included in this condition).
Do you know this Bluetooth code? Does it make sense? Is
there anyone I can ask to confirm it?
static pa_hook_result_t
profile_available_hook_callback(pa_core *c,
pa_card_profile *profile, void *userdata) {
pa_card *card;
const char *s;
bool is_active_profile;
pa_card_profile *selected_profile;
pa_assert(c);
pa_assert(profile);
pa_assert_se((card = profile->card));
/* Only consider bluetooth cards */
s = pa_proplist_gets(card->proplist, PA_PROP_DEVICE_BUS);
if (!s || !pa_streq(s, "bluetooth"))
return PA_HOOK_OK;
/* Do not automatically switch profiles for headsets,
just in case */
/* TODO: remove a2dp and hsp when we remove BlueZ 4
support */
if (pa_streq(profile->name, "hsp") ||
pa_streq(profile->name, "a2dp") || pa_streq(profile->name,
"a2dp_sink") ||
- pa_streq(profile->name, "a2dp_source") ||
pa_streq(profile->name, "headset_head_unit"))
+ pa_streq(profile->name, "headset_head_unit")) {
return PA_HOOK_OK;
…
It seemed it worked J, but the freezing issue still there L.
When an a2dp connection is lost, pa would freeze when
trying to reconnect and reload the Bluetooth modules.
gdb output:
(gdb) thread apply all bt
Thread 1 (process 1998):
#0 arm_modulus (p=1031, m=123328564) at
./ldso/ldso/arm/dl-sysdep.h:29
#1 _dl_lookup_sysv_hash (type_class=<optimized out>,
undef_name=<optimized out>, hash=123328564,
symtab=0xb6d0f3ec,
tpnt=0xb6fc5508) at ldso/ldso/dl-hash.c:255
#2 _dl_find_hash (
name=name@entry=0xbec1b5c0
"module_bluez5_device_LTX_pa__get_deprecated",
scope=<optimized out>, mytpnt=mytpnt@entry=0x0,
type_class=type_class@entry=-2147483648,
sym_ref=sym_ref@entry=0xbec1b558)
at ldso/ldso/dl-hash.c:339
#3 0xb6d86b1c in do_dlsym (caller_address=<optimized out>,
name=0xbec1b5c0
"module_bluez5_device_LTX_pa__get_deprecated",
vhandle=<optimized out>) at ldso/libdl/libdl.c:733
#4 dlsym (vhandle=<optimized out>,
name=0xbec1b5c0
"module_bluez5_device_LTX_pa__get_deprecated")
at ldso/libdl/libdl.c:765
#5 0x000116d8 in bind_now_find_sym (d=<optimized out>,
m=<optimized out>,
symbol=<optimized out>) at daemon/ltdl-bind-now.c:101
#6 0xb6e039b8 in lt_dlsym () from /usr/lib/libltdl.so.7
#7 0xb6f5b400 in pa_load_sym (handle=0x5e8f8,
module=module@entry=0xb686247a "module-bluez5-device",
symbol=0xb6fa3121 "pa__get_deprecated") at
pulsecore/ltdl-helper.c:42
---Type <return> to continue, or q <return> to quit---
#8 0xb6f5d128 in pa_module_load (c=0x24f00,
name=0xb686247a "module-bluez5-device",
argument=argument@entry=0x5e2b0
"path=/org/bluez/hci0/dev_98_D6_F7_34_98_E8") at
pulsecore/module.c:151
#9 0xb6861ee0 in device_connection_changed_cb
(y=<optimized out>, d=0x50bb8,
u=0x38950) at
modules/bluetooth/module-bluez5-discover.c:77
#10 0xb6f5b1a4 in pa_hook_fire (hook=0x37840, data=0x50bb8)
at pulsecore/hook-list.c:104
#11 0xb684f8cc in endpoint_set_configuration
(m=m@entry=0x50f10,
userdata=userdata@entry=0x37830, conn=<optimized out>)
at modules/bluetooth/bluez5-util.c:1313
#12 0xb684fcdc in endpoint_handler (c=<optimized out>,
m=m@entry=0x50f10,
userdata=userdata@entry=0x37830) at
modules/bluetooth/bluez5-util.c:1517
#13 0xb6ddf800 in _dbus_object_tree_dispatch_and_unlock
(tree=0x399e0,
message=message@entry=0x50f10,
found_object=found_object@entry=0xbec1b99c)
at dbus-object-tree.c:1018
#14 0xb6dd1104 in dbus_connection_dispatch
(connection=0x39c28)
at dbus-connection.c:4718
#15 0xb6ec81b4 in dispatch_cb (ea=0x2124c, ev=0x35a20,
userdata=0x407)
at pulsecore/dbus-util.c:53
#16 0xb6f1a798 in dispatch_defer (m=<optimized out>) at
pulse/mainloop.c:680
#17 pa_mainloop_dispatch (m=m@entry=0x21208) at
pulse/mainloop.c:889
#18 0xb6f1ab98 in pa_mainloop_iterate (m=m@entry=0x21208,
block=block@entry=1,
---Type <return> to continue, or q <return> to quit---
retval=retval@entry=0xbec1ba9c) at pulse/mainloop.c:929
#19 0xb6f1abfc in pa_mainloop_run (m=m@entry=0x21208,
retval=0xbec1ba9c,
retval@entry=0xbec1ba94) at pulse/mainloop.c:944
#20 0x0000d9ec in main (argc=<optimized out>,
argv=<optimized out>)
at daemon/main.c:1134
-----Original Message-----
From: Tanu Kaskinen [mailto:[email protected]]
Sent: Friday, August 14, 2015 12:00 PM
To: Eytan Naim; [email protected]
<mailto:[email protected]>
Subject: Re: [pulseaudio-discuss] pulseaudio a2dp
disconnect problem
On Thu, 2015-08-13 at 12:35 +0000, Eytan Naim wrote:
> Hi Tanu,
>
> Thanks for the reply.
>
> I think that the loopback module shouldn’t be unloaded
each time
> steaming stops for the simple reason that it is loaded
when connection
> is established, and not when streaming starts.
Yes, that's oddly asymmetric, and should perhaps be fixed.
That said, as long as module-loopback gets loaded again
when the streaming continues, the current logic shouldn't
necessarily cause too much trouble. In your case
module-loopback doesn't get loaded again, but that might
be because pulseaudio gets stuck before that has a chance
to happen.
> I get all kind of PulseAudio problems, for example in
the example
> below, PulseAudio success to stream in the start, but
after pausing
> and playing again PulseAudio act differently.
>
> - It looks like PulseAudio has problem to handle
changing connection
> state or something.
>
>
>
> The below log was produced by the following steps:
>
> a) connection establishment
>
> b) streaming session
>
> c) stop from remote device
>
> d) unloading loopback module
>
> e) toggling streaming start/stop without PulseAudio
suitable
> response
>
> f) pacmd failure for long time (more then 3-4
minutes). – so
> it’s probably not a dbus thing.
>
>
>
> Please notice that each time I try a test, something a
little
> different happens- but it always has to do with modules
> unloading/PulseAudio doesn’t response
Getting stuck is the most interesting problem here. Can
you run pulseaudio in gdb, and when it gets stuck, stop
and give command "thread apply all bt"?
--
Tanu
It is correct that the profile is set to "off" when a stream
stops. The a2dp connection
is torn down on the bluetooth end, so it would not make sense
to keep the profile in
pulesaudio. This is definitely not the cause of your problem.
And actually I cannot
see that it's asymmetric. The loopback module is loaded as
soon as the profile is
switched to a2dp and unloaded as soon as the profile changes
to "off".
BTW, you can avoid loading and unloading the loopback module
automatically by
loading module-bluetooth-policy with argument a2dp_source=0.
But then you have
to load the loopback manually and move it to the right source.
Maybe it is a good idea
to test that because the issue might also be caused by
module-bluetooth-policy.
The phone application I wrote handles insertion of loopback
modues and does not
rely on module-bluetuetooth policy for that. Up to now I have
not seen a similar
issue, the application reacts to switches between a2dp/hsp/off
without problems.
Georg
Hi,
my main point was that you should test it with a2dp_source=0 as
argument to module-bluetooth-policy, because I am using it that
way and it works without issues. It might help to narrow down the
problem.
I won't argue about the symmetry.
Regards
Georg
I just tested it for my setup. When I connect my phone (Galaxy S6), it
initially
connects the HSP profile (probably because I am running ofono). When I
start
playing music it switches to a2dp and when I pause it goes to off.
Resuming the
stream works, it goes back to a2dp as expected.
But I hit another issue: When I completely disconnect the phone and
re-connect it
and then try to play music again, pulseaudio crashes with following
message:
[pulseaudio] source.h: Assertion 'pa_object_refcnt(pa_object_cast(o))
> 0' failed at ./pulsecore/source.h:249, function
pa_source_assert_ref(). Aborting.
Regards
Georg
