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>
