[pulseaudio-discuss] pulseaudio a2dp disconnect problem
Georg Chini
georg at chini.tk
Sun Aug 16 06:06:49 PDT 2015
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:pulseaudio-discuss-bounces at lists.freedesktop.org] *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 at entry=0xbec1b5c0
>> "module_bluez5_device_LTX_pa__get_deprecated",
>>
>> scope=<optimized out>, mytpnt=mytpnt at entry=0x0,
>>
>> type_class=type_class at entry=-2147483648,
>> sym_ref=sym_ref at 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 at 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 at 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 at entry=0x50f10,
>>
>> userdata=userdata at entry=0x37830, conn=<optimized out>)
>>
>> at modules/bluetooth/bluez5-util.c:1313
>>
>> #12 0xb684fcdc in endpoint_handler (c=<optimized out>,
>> m=m at entry=0x50f10,
>>
>> userdata=userdata at entry=0x37830) at
>> modules/bluetooth/bluez5-util.c:1517
>>
>> #13 0xb6ddf800 in _dbus_object_tree_dispatch_and_unlock
>> (tree=0x399e0,
>>
>> message=message at entry=0x50f10,
>> found_object=found_object at 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 at entry=0x21208) at pulse/mainloop.c:889
>>
>> #18 0xb6f1ab98 in pa_mainloop_iterate (m=m at entry=0x21208,
>> block=block at entry=1,
>>
>> ---Type <return> to continue, or q <return> to quit---
>>
>> retval=retval at entry=0xbec1ba9c) at pulse/mainloop.c:929
>>
>> #19 0xb6f1abfc in pa_mainloop_run (m=m at entry=0x21208,
>> retval=0xbec1ba9c,
>>
>> retval at 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:tanuk at iki.fi]
>> Sent: Friday, August 14, 2015 12:00 PM
>> To: Eytan Naim; pulseaudio-discuss at lists.freedesktop.org
>> <mailto:pulseaudio-discuss at lists.freedesktop.org>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150816/549700a5/attachment-0001.html>
More information about the pulseaudio-discuss
mailing list