[pulseaudio-discuss] pulseaudio a2dp disconnect problem
Georg Chini
georg at chini.tk
Sun Aug 16 09:41:19 PDT 2015
On 16.08.2015 15:20, Eytan Naim wrote:
>
> 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:pulseaudio-discuss-bounces at lists.freedesktop.org] *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: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
>
>
Yes, I do not see any freezes and everything works as expected
(apart from the crash mentioned above). But - as already said -
I am using module-bluetooth-policy with a2dp_source=0 and
hfgw=0 and let my application take care of the loopback modules.
Georg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150816/5e0d6bd5/attachment-0001.html>
More information about the pulseaudio-discuss
mailing list