On Sat, 2018-01-20 at 10:35 +0200, Tőkés Attila wrote: > Hi Everyone, > > I'm trying to use a Bluetooth speaker with Raspberry Pi 3 in HSP mode > with PulseAudio. > > Based on the information I found on the web (blogs / forums / mailing > list archives), apparently, HSP does not really works with the > Rasberry Pi's built in BCM43438 chip. I didn't found the exact reason > yet. Some people suggest it may be a problem with the BCM43438 > firmware or with the kernel driver. A2DP, and HSP with USB Bluetooth > dongles are reported to be working fine. (The most complete > description I found about the problem is: > http://youness.net/raspberry-pi/bluetooth-headset-raspberry-pi-3-ad2p-hsp) > > I think it would be useful to get clear picture about the problem. And > maybe we could try to fix it. > > Does anyone managed to figure out what exactly the problem is? > > I started investigating the issue, but didn't got any result yet. I > didn't had too much experience with the Linux's Bluetooth stack, so > some help with the further investigation would be useful. > > ---- > > Bellow are some details of my investigation. > > Hardware: Raspberry Pi 3 + JBL GO! Bluetooth speaker > > Kernel: raspberrypi 4.14.14-v7 > BlueZ: 5.43 > PulseAudio: 11.1 > > Summary: > - BCM43438's driver is sucessfuly loaded, it's firmware is uploaded successfully > - the Bluetooth speaker gets detected and the pairing / connection works fine > - PulseAudio detects the speaker as a card > - both the headset_head_unit and a2dp_sink profiles are shown by > `pacmd list-cards` and can be set with `pacmd set-card-profile` > - with the a2dp_sink profile, the audio playback works fine (tested > with `paplay`) > - with the headset_head_unit profile, `paplay` gets stuck at start a > no audio is played (`parecord` does the same) > > I started booth BlueZ and PulseAudio in debug mode, but found nothing > obviuosly wrong (at least for me :P) in the logs. Also did a HCI dump. > > Linking the following logs (uploaded to PasteBin; they are too long > inline them): > - the Blootoothd's log - https://pastebin.com/WC17Ze0r > - the PlulseAudio's log - https://pastebin.com/jUjqjuhC > - the output of the PA commands - https://pastebin.com/wvRzdTEx > - the output of some BL Tools (sdptool / bluetoothctl / hciconfig) - > https://pastebin.com/Ax7XYr94 > - the HCI dump -https://pastebin.com/zqhqKu57 > > SCO dump did not managed to get. > > I executed the following steps: > (the steps are marked in the log files too): > - start Blootoothd > - start PulseAudio > - powered on the Bloothooth speaker > - tried to play some audio > $ pacmd list cards > $ pacmd set-card-profile 1 headset_head_unit > $ paplay -v -d bluez_sink.78_44_05_4B_4F_FF.headset_head_unit > /tmp/h2g2.ogg (gets stuck) > $ pacmd set-card-profile 1 a2dp_sink > $ paplay -v -d bluez_sink.78_44_05_4B_4F_FF.a2dp_sink /tmp/h2g2.ogg (works) HSP playback getting stuck is a fairly common problem (affecting multiple bluetooth adapters from different vendors). Solutions for the problem are known for a few adapters, but not this one. The issue is documented here (the "HSP problem: the bluetooth sink and source are created, but no audio is being transmitted" section): https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index8h3 As you can read there, the underlying problem in the known cases is either that firmware is missing or the SCO audio routing is wrong in the adapter. Changing the routing requires (at least in the known cases) a vendor-specific magic command. I don't know how to figure out the correct command. On one Broadcom chip this does the trick: "hcitool cmd 0x3F 0x01C 0x01 0x02 0x00 0x01 0x01", but I don't know how likely that is to work on a different chip. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
