[pulseaudio-discuss] pulseaudio a2dp disconnect problem
tanuk at iki.fi
Mon Aug 17 05:19:21 PDT 2015
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
> 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
> 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
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. 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?
More information about the pulseaudio-discuss