On Sun, 2015-08-16 at 10:26 +0000, 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). module-bluetooth-policy is supposed to automatically switch profiles when the remote device stops streaming, so your change is not appropriate. Changing the profile to "off" is intentional. If the asymmetry is to be fixed, I think it's better to postpone the activation of the "a2dp_source" profile until the streaming starts. > It seemed it worked â?º, but the freezing issue still there â?¹. > > 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 This is a strange place to get stuck. Googling for arm_modulus gives mostly results in uClibc source code. arm_modulus() doesn't seem to do any IO that could get stuck[1]. Maybe there's an infinite loop? Does pulseaudio consume cpu when it's stuck? If you try getting a backtrace again, is the trace always the same? [1] http://git.uclibc.org/uClibc/plain/ldso/ldso/arm/dl-sysdep.h -- Tanu
