[pulseaudio-discuss] No sound on Bluetooth headset with HSP/HFP profiles and RTL8723BE chipset

Mario Sanchez Prada mario at endlessm.com
Tue Jan 27 04:27:06 PST 2015


Hi,

I'm seeing and strange issue happening with PulseAudio and the
integrated Bluetooth card of my barebone computer and, after a couple of
days debugging this, I still could not figure out what the problem is,
so I thought I would ask for some help here, in case someone was able to
provide some help.

As a bit of extra context, I'm trying to use a Plantronics M50 headset
with the BT card coming with the RTL8723BE chipset of my Gygabyte Brix
2807 [1] and Fedora 21's package for PulseAudio 5.0, which backports the
patches needed to add back support for Bluez5 and headset profiles (see
[2]).

The problem I'm seeing is that, after pairing and connecting my BT
headset to the computer I can neither get any sound out of the headphone
nor use the mic, even if I explicitly select them in the "sound" panel
of gnome-control-center, as long as the HSP/HFP profile is selected. If
I select the A2DP profile, though, I do get it to work as an output
device, but then I get silence again if I switch back to the HSP/HFP
profile.

Additionally, I've observed that PA will be basically sleeping while
playing a .wav file with paplay for as long as I keep the HSP/HFP
profile, resuming the play once I switch back to another output device
(e.g. HDMI). See attached the output of `thread apply all bt` after
manually breaking the sleeping execution in gdb, where it seems all the
threads are sleeping, hence the silence I guess.

Now, using an external BT usb dongle in my barebone instead of the
integrated BT card, or even using exactly the same software stack in a
different computer with a different BT chipset (e.g. my Thinkpad x201),
gets the BT headset working as expected with the HSP/HFP profile, both
as an input and output device. That makes me think it could perhaps be a
problem outside of PA, but I'm not 100% sure yet.

In any case, I've compared verbose logs from bluetoothd and pulseaudio,
as well as the output of different pactl commands, between the working
(external dongle, thinkpad) and non-working (Gygabayte Brix) scenarios,
but I could not spot any significant difference yet.

Still, I've observed in the working scenario that the for(;;) loop seems
keep looping all the time because there is a pa_source available and
linked from which it seems to be reading data through
sco_process_push(). That read causes the do_write variable to take a
positive value, which will later on result on sco_process_render() being
called too, thus sending data back to the headset.

In the non-working scenario, though, no data from the headset is being
read at all in thread_func() because the (pollfd && (pollfd->revents &
POLLIN)) condition inside the "if" block for the linked source always
evaluates to false, and I wonder whether this might be the reason why
everything gets stalled like this.

What do you think? Does anyone here have any clue what could be going on
here?

Goes without saying that any help would be very much appreciated! :)

Thanks a lot in advance,
Mario

[1] http://www.gigabyte.com/products/product-page.aspx?pid=5038
[2] http://pkgs.fedoraproject.org/cgit/pulseaudio.git/tree/?h=f21
-------------- next part --------------
Program received signal SIGINT, Interrupt.
0xb77b1424 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 4 (Thread 0xb13ffb40 (LWP 3367)):
#0  0xb77b1424 in __kernel_vsyscall ()
#1  0xb74a9ea0 in __GI_ppoll (fds=0x8d38c78, nfds=3, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57
#2  0xb7737ef5 in pa_rtpoll_run (p=0x8cdad58, wait_op=true) at pulsecore/rtpoll.c:314
#3  0xb28cde20 in thread_func (userdata=0x8ce0258) at modules/bluetooth/module-bluez5-device.c:1501
#4  0xb76d893d in internal_thread_func (userdata=0x8d62aa0) at pulsecore/thread-posix.c:83
#5  0xb7587d78 in start_thread (arg=0xb13ffb40) at pthread_create.c:311
#6  0xb74b93ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 3 (Thread 0xb2736b40 (LWP 3334)):
#0  0xb77b1424 in __kernel_vsyscall ()
#1  0xb74a9ea0 in __GI_ppoll (fds=0x8d42328, nfds=3, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57
#2  0xb7737ef5 in pa_rtpoll_run (p=0x8cd5760, wait_op=true) at pulsecore/rtpoll.c:314
#3  0xb2766b58 in thread_func (userdata=0x8d08e80) at modules/alsa/alsa-sink.c:1800
#4  0xb76d893d in internal_thread_func (userdata=0x8ced110) at pulsecore/thread-posix.c:83
#5  0xb7587d78 in start_thread (arg=0xb2736b40) at pthread_create.c:311
#6  0xb74b93ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 2 (Thread 0xb1dffb40 (LWP 3335)):
#0  0xb77b1424 in __kernel_vsyscall ()
#1  0xb74a9ea0 in __GI_ppoll (fds=0x8d09210, nfds=4, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57
#2  0xb7737ef5 in pa_rtpoll_run (p=0x8ceaf78, wait_op=true) at pulsecore/rtpoll.c:314
#3  0xb276fce8 in thread_func (userdata=0x8ce9828) at modules/alsa/alsa-source.c:1519
#4  0xb76d893d in internal_thread_func (userdata=0x8cffef8) at pulsecore/thread-posix.c:83
#5  0xb7587d78 in start_thread (arg=0xb1dffb40) at pthread_create.c:311
#6  0xb74b93ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 1 (Thread 0xb6c4e780 (LWP 3333)):
#0  0xb77b1424 in __kernel_vsyscall ()
#1  0xb74a9ea0 in __GI_ppoll (fds=0x8ce7290, nfds=23, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57
#2  0xb7646433 in pa_mainloop_poll (m=0x8cbac08) at pulse/mainloop.c:859
#3  0xb76467cb in pa_mainloop_iterate (m=0x8cbac08, block=1, retval=0xbfc29420) at pulse/mainloop.c:933
#4  0xb7646845 in pa_mainloop_run (m=0x8cbac08, retval=0xbfc29420) at pulse/mainloop.c:951
#5  0x08054926 in main (argc=2, argv=0xbfc29654) at daemon/main.c:1155



More information about the pulseaudio-discuss mailing list