<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> Hi Tanu,<o:p></o:p> Thanks for your advice and cooperation.<o:p></o:p> As a result of the loopback_module asymmetric oddity, I compared "pacmd list" output command between two states (you can see attached files):<o:p></o:p> <![if !supportLists]>1. <![endif]>After connection establishment, and before streaming starts.<o:p></o:p> <![if !supportLists]>2. <![endif]>After streaming stops.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> 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).<o:p></o:p> Do you know this Bluetooth code? Does it make sense? Is there anyone I can ask to confirm it?<o:p></o:p> <o:p> </o:p> static pa_hook_result_t profile_available_hook_callback(pa_core *c, pa_card_profile *profile, void *userdata) {<o:p></o:p> pa_card *card;<o:p></o:p> const char *s;<o:p></o:p> bool is_active_profile;<o:p></o:p> pa_card_profile *selected_profile;<o:p></o:p> <o:p> </o:p> pa_assert(c);<o:p></o:p> pa_assert(profile);<o:p></o:p> pa_assert_se((card = profile->card));<o:p></o:p> <o:p> </o:p> /* Only consider bluetooth cards */<o:p></o:p> s = pa_proplist_gets(card->proplist, PA_PROP_DEVICE_BUS);<o:p></o:p> if (!s || !pa_streq(s, "bluetooth"))<o:p></o:p> return PA_HOOK_OK;<o:p></o:p> <o:p> </o:p> /* Do not automatically switch profiles for headsets, just in case */<o:p></o:p> /* TODO: remove a2dp and hsp when we remove BlueZ 4 support */<o:p></o:p> if (pa_streq(profile->name, "hsp") || pa_streq(profile->name, "a2dp") || pa_streq(profile->name, "a2dp_sink") ||<o:p></o:p> - pa_streq(profile->name, "a2dp_source") || pa_streq(profile->name, "headset_head_unit"))<o:p></o:p> + pa_streq(profile->name, "headset_head_unit")) {<o:p></o:p> return PA_HOOK_OK;<o:p></o:p> …<o:p></o:p> <o:p> </o:p> It seemed it worked J, but the freezing issue still there L.<o:p></o:p> When an a2dp connection is lost, pa would freeze when trying to reconnect and reload the Bluetooth modules.<o:p></o:p> <o:p> </o:p> gdb output:<o:p></o:p> (gdb) thread apply all bt<o:p></o:p> <o:p> </o:p> Thread 1 (process 1998):<o:p></o:p> #0 arm_modulus (p=1031, m=123328564) at ./ldso/ldso/arm/dl-sysdep.h:29<o:p></o:p> #1 _dl_lookup_sysv_hash (type_class=<optimized out>,<o:p></o:p> undef_name=<optimized out>, hash=123328564, symtab=0xb6d0f3ec,<o:p></o:p> tpnt=0xb6fc5508) at ldso/ldso/dl-hash.c:255<o:p></o:p> #2 _dl_find_hash (<o:p></o:p> name=name@entry=0xbec1b5c0 "module_bluez5_device_LTX_pa__get_deprecated",<o:p></o:p> scope=<optimized out>, mytpnt=mytpnt@entry=0x0,<o:p></o:p> type_class=type_class@entry=-2147483648, sym_ref=sym_ref@entry=0xbec1b558)<o:p></o:p> at ldso/ldso/dl-hash.c:339<o:p></o:p> #3 0xb6d86b1c in do_dlsym (caller_address=<optimized out>,<o:p></o:p> name=0xbec1b5c0 "module_bluez5_device_LTX_pa__get_deprecated",<o:p></o:p> vhandle=<optimized out>) at ldso/libdl/libdl.c:733<o:p></o:p> #4 dlsym (vhandle=<optimized out>,<o:p></o:p> name=0xbec1b5c0 "module_bluez5_device_LTX_pa__get_deprecated")<o:p></o:p> at ldso/libdl/libdl.c:765<o:p></o:p> #5 0x000116d8 in bind_now_find_sym (d=<optimized out>, m=<optimized out>,<o:p></o:p> symbol=<optimized out>) at daemon/ltdl-bind-now.c:101<o:p></o:p> #6 0xb6e039b8 in lt_dlsym () from /usr/lib/libltdl.so.7<o:p></o:p> #7 0xb6f5b400 in pa_load_sym (handle=0x5e8f8,<o:p></o:p> module=module@entry=0xb686247a "module-bluez5-device",<o:p></o:p> symbol=0xb6fa3121 "pa__get_deprecated") at pulsecore/ltdl-helper.c:42<o:p></o:p> ---Type <return> to continue, or q <return> to quit---<o:p></o:p> #8 0xb6f5d128 in pa_module_load (c=0x24f00,<o:p></o:p> name=0xb686247a "module-bluez5-device",<o:p></o:p> argument=argument@entry=0x5e2b0 "path=/org/bluez/hci0/dev_98_D6_F7_34_98_E8") at pulsecore/module.c:151<o:p></o:p> #9 0xb6861ee0 in device_connection_changed_cb (y=<optimized out>, d=0x50bb8,<o:p></o:p> u=0x38950) at modules/bluetooth/module-bluez5-discover.c:77<o:p></o:p> #10 0xb6f5b1a4 in pa_hook_fire (hook=0x37840, data=0x50bb8)<o:p></o:p> at pulsecore/hook-list.c:104<o:p></o:p> #11 0xb684f8cc in endpoint_set_configuration (m=m@entry=0x50f10,<o:p></o:p> userdata=userdata@entry=0x37830, conn=<optimized out>)<o:p></o:p> at modules/bluetooth/bluez5-util.c:1313<o:p></o:p> #12 0xb684fcdc in endpoint_handler (c=<optimized out>, m=m@entry=0x50f10,<o:p></o:p> userdata=userdata@entry=0x37830) at modules/bluetooth/bluez5-util.c:1517<o:p></o:p> #13 0xb6ddf800 in _dbus_object_tree_dispatch_and_unlock (tree=0x399e0,<o:p></o:p> message=message@entry=0x50f10, found_object=found_object@entry=0xbec1b99c)<o:p></o:p> at dbus-object-tree.c:1018<o:p></o:p> #14 0xb6dd1104 in dbus_connection_dispatch (connection=0x39c28)<o:p></o:p> at dbus-connection.c:4718<o:p></o:p> #15 0xb6ec81b4 in dispatch_cb (ea=0x2124c, ev=0x35a20, userdata=0x407)<o:p></o:p> at pulsecore/dbus-util.c:53<o:p></o:p> #16 0xb6f1a798 in dispatch_defer (m=<optimized out>) at pulse/mainloop.c:680<o:p></o:p> #17 pa_mainloop_dispatch (m=m@entry=0x21208) at pulse/mainloop.c:889<o:p></o:p> #18 0xb6f1ab98 in pa_mainloop_iterate (m=m@entry=0x21208, block=block@entry=1,<o:p></o:p> ---Type <return> to continue, or q <return> to quit---<o:p></o:p> retval=retval@entry=0xbec1ba9c) at pulse/mainloop.c:929<o:p></o:p> #19 0xb6f1abfc in pa_mainloop_run (m=m@entry=0x21208, retval=0xbec1ba9c,<o:p></o:p> retval@entry=0xbec1ba94) at pulse/mainloop.c:944<o:p></o:p> #20 0x0000d9ec in main (argc=<optimized out>, argv=<optimized out>)<o:p></o:p> at daemon/main.c:1134<o:p></o:p> <o:p> </o:p> <o:p> </o:p> -----Original Message----- From: Tanu Kaskinen [mailto:tanuk@iki.fi] Sent: Friday, August 14, 2015 12:00 PM To: Eytan Naim; pulseaudio-discuss@lists.freedesktop.org Subject: Re: [pulseaudio-discuss] pulseaudio a2dp disconnect problem <o:p> </o:p> On Thu, 2015-08-13 at 12:35 +0000, Eytan Naim wrote:<o:p></o:p> > Hi Tanu,<o:p></o:p> > <o:p></o:p> > Thanks for the reply.<o:p></o:p> > <o:p></o:p> > I think that the loopback module shouldn’t be unloaded each time <o:p></o:p> > steaming stops for the simple reason that it is loaded when connection <o:p></o:p> > is established, and not when streaming starts.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> > I get all kind of PulseAudio problems, for example in the example <o:p></o:p> > below, PulseAudio success to stream in the start, but after pausing <o:p></o:p> > and playing again PulseAudio act differently.<o:p></o:p> > <o:p></o:p> > - It looks like PulseAudio has problem to handle changing connection <o:p></o:p> > state or something.<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > <o:p></o:p> > The below log was produced by the following steps:<o:p></o:p> > <o:p></o:p> > a) connection establishment<o:p></o:p> > <o:p></o:p> > b) streaming session<o:p></o:p> > <o:p></o:p> > c) stop from remote device<o:p></o:p> > <o:p></o:p> > d) unloading loopback module<o:p></o:p> > <o:p></o:p> > e) toggling streaming start/stop without PulseAudio suitable <o:p></o:p> > response<o:p></o:p> > <o:p></o:p> > f) pacmd failure for long time (more then 3-4 minutes). – so <o:p></o:p> > it’s probably not a dbus thing.<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > <o:p></o:p> > Please notice that each time I try a test, something a little <o:p></o:p> > different happens- but it always has to do with modules <o:p></o:p> > unloading/PulseAudio doesn’t response<o:p></o:p> <o:p> </o:p> 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"?<o:p></o:p> <o:p> </o:p> --<o:p></o:p> Tanu<o:p></o:p> </div> </body> </html>