Bluetooth HSP/HFP not working in Raspberry PI 3 #2229
Comments
|
I'm facing the same issue too |
1 similar comment
|
I'm facing the same issue too |
|
Would it be possible for commenters to try the latest kernel (4.14) and see if the problems persists? Note, this is a testing branch, so should not be done on a critical system unless it's well backed up! sudo BRANCH=next rpi-update |
JamesH65
added
the
Waiting for external input
|
It's not a kernel issue - it's a BlueZ limitation. As of version 5.0, BlueZ does not support HFP or HSP, only A2DP. I've not found an official explanation from BlueZ, but there are some notes from the PulseAudio devs here: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/ If anyone knows of a solution that doesn't involve installing BlueZ 4 as well I'll be interested to hear it. |
|
To get HFP/HSP working properly you'll need PulseAudio 11 https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/ |
|
Seems that, we have a solution to use the HSP profile with Raspberry Pi 3’s built in BCM43438 chip. The culprit was the so called SCO audio routing. HSP / HFP uses SCO audio packets to transmit audio and in order to make PulseAudio work the packets must be routed to the HCI interface. This can be done by sending the the following HCI command: After issuing this command, both More details here: |
|
Ooh, interesting. That hci command that could easily be added to the Pi-specific script /usr/bin/btuart if it solves the problem. |
|
Hi, I confirm that this command solves the problem. |
|
Hi, hcitool cmd can solve the connect problem in HSP/HFP mode, but the sound is terrible, have distortion. Thanks! |
|
@kp339, the sound is a little noisy for me too. I contacted the Cypress's support, their FW team is checking the CYW43438's firmware right now. |
|
@bluetiger9 If there is any progress, please let me know. Thanks！ |
|
It happens to me too, the sound is too distorted until the speech recognition can't even work. Please let me know how to improve the sound quality. |
|
The problem was identified as a timing issue in PulseAudio. In an nutshell, PulseAudio uses a hard-coded (e)SCO packet size of 48 bytes, instead of using the packet size negotiated at the eSCO connect (ex 60 bytes). The timing logic used for SCO connections, is to send (e)SCO packets (one at a time), at each SCO packet received. If the negotiated packet size is bigger (ex 60 bytes) than the hard-coded 48 bytes, the SCO packets are received at a lower rate, which causes PulseAudio to send the SCO packets way too slow. More details on the following [pulseaudio-discuss] thread: As a workaround PulseAudio 11.1 can be used, with the (note: be aware that this setting breaks the compatibility with some adapters) The PulseAudio 11.1 is not yet available for Raspbian, but it can be compiled from source: Cheers, |
|
Yeah, and if your PulseAudio's version lower than 11.1, you can try this way:
Thanks Attila. |
|
Hi @bluetiger9 the issue seems to be fixed, sound improves dramatically, thanks! However, I noticed that I can't seem to play anything in my root after using this (I need to be in the root to run manipulate GPIO on my pi), is there any fix? The audio does play with paplay audio.wav, but if I go to my root, paplay audio.wav gives error as such: No protocol specified Any idea how to fix? |
|
Can anybody give a précis of the current state of this? Sounds like it's pretty much fixed? Related to #1401? |
|
Yes, the two issues are (already) linked. The next Raspbian release (due shortly) includes a startup script to send the HCI command mentioned above that switches SCO traffic to the HCI interface. |
|
Indeed. Issues with SCO traffic routing and mtu packet size are fixed. I can confirm that but.... I am using R-Pi3B+ with /var/log/kern.log shows something like this when the error occurs: Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649493] Bluetooth: hci0 command 0x0c24 tx timeout The only way I have found until now to get it going again is re-booting the RaspberryPi. Reloading bluetooth (sudo systemctl relaod bluetooth) does not solve this. And unloading the kernel modules (rmmod bluetooth) is impossible as the module is "in use" Anybody knows of any progress in getting newer BCM43438 firmware? Or knows how to restart bluetooth without rebooting? Thanks, Engelbert |
|
Hi everyone,
Right now, I have the same problem and I am working in solved it. I
found this link [1].
I have added this link:
ln -sf /lib/firmware/brcm/BCM4345C0 /lib/firmware/brcm/hcd BCM.hcd
And the log has changed:
[ 12.708529] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 12.710947] Bluetooth: BNEP filters: protocol multicast
[ 12.713474] Bluetooth: BNEP socket layer initialized
[ 13.104891] Bluetooth: hci0: BCM: chip id 107
[ 13.109021] Bluetooth: hci0: BCM: features 0x2f
[ 13.133823] Bluetooth: hci0: BCM4345C0
[ 13.135972] Bluetooth: hci0: BCM (003.001.025) build 0000
[ 15.751469] Bluetooth: hci0 command 0xfc4c tx timeout
[ 21.973921] uart-pl011 3f201000.serial: no DMA platform data
[ 24.151397] Bluetooth: hci0: BCM: Patch command fc4c failed (-110)
[ 24.154283] Bluetooth: hci0: BCM: Patch failed (-110)
[ 24.157206] Bluetooth: hci0 sending frame failed (-49)
[ 26.231385] Bluetooth: hci0 command 0x0c03 tx timeout
But BT does not no work yet.... I will continue to figure out a solution.
Best regards.
[1] http://www.yamanoue.atnifty.com/2018/07/raspberry-pi-3bbluetooth.html
Oscar Gomez Fuente
TST Sistemas
www.tst-sistemas.es
|
|
I use the following script to reset the bluetooth interface - I call it sudo killall hciattach
if grep -a Zero /proc/device-tree/model; then
raspi-gpio set 45 op dl
sleep 1
raspi-gpio set 45 op dh
else
/opt/vc/bin/vcmailbox 0x38041 8 8 128 0
sleep 1
/opt/vc/bin/vcmailbox 0x38041 8 8 128 1
fi
sleep 4
sudo btuart |
|
Hi Phil,
Thank you very much for your help. Could you explain a bit more?
1. The GPIO number associated with the pin reset of the BT module (on
the Raspberry Pi 3B+), Is it 45?
2. You reset only the BT or the WiFi too?
3. What the sequence you have to do: High - sleep 1 - Low or Low -
sleep 1 - High
Best regards.
|
|
|
@CliveWongTohSoon, check out the following page: |
|
Phil, Thanks a lot. That indeed resets the bluetooth device and communication is re-established on my R-Pi3B+. Now of course I would like to know why it gets stuck but that is probably a firmware problem somewhere. Would not know how to debug that. Another thing I noticed is that after every HFP call I make the usage count of bluetooth kernel module is increasing by 1. Actually during the call it is increasing by 2 and when the call is finished only a +1 remains. So something is released but not everything. Anybody any hints on how to attack this? Or is there a way to forcefully reload the bluetooth kernel module at regular interval to reset the count? "rmmod bluetooth" does not work obviously as the count is not 0 so the module is "in use" Thanks, Engelbert |
Although I understand the basic concepts I've never written a Bluetooth app of any description. However, a simple, repeatable problem like you describe sounds very fixable. If you can reduce your code down to the simple test and upload it somewhere with simple instructions (including links for installing any non-standard dependencies) I can take a look when I get a moment. |
|
Hi Engelbert and Phill,
Another thing I noticed is that after every HFP call I make the usage count of bluetooth kernel module is increasing by 1. Actually during the call it is increasing by 2 and when the call is finished only a +1 remains. So something is released but not everything.
Anybody any hints on how to attack this? Or is there a way to forcefully reload the bluetooth kernel module at regular interval to reset the count? "rmmod bluetooth" does not work obviously as the count is not 0 so the module is "in use"
Yes, I noticed this too. I think you mean the 40 number, don't you?
# rfkill list
0: phy0: wlan
Soft blocked: no
Hard blocked: no
40: hci0: bluetooth
Soft blocked: no
Hard blocked: no
The questions are:
1. What happens if this count increased in an infinity mode?
2. What is the maximum value?
3. If this number reaches the maximum value, Does it restart again from 0?
Best regards.
|
|
Well actually this is what I see: After the call: But I have no clue what is now exactly increasing and indeed as you point out does it harm? An "rfkill list" on my R-Pi only shows this btw: rfkill list3: hci0: Bluetooth |
|
Phil, Below how to do that. (to get it down to the very basic) but actually it is not a bluetooth app that I am developing it is actually getting HFP working stable (also using Ofono and Pulseaudio as part of this) so it continues to work over a long period of time. You will need the ofono source to be installed as it contains a number of python scripts that will allow you to use ofono to make calls etc. The basics actually comes down to this:
During the call 2 "sound channels" are opened via bluetooth to get the audio to/from the R-Pi. Maybe one of them is not released correctly? Could of course also be a PulseAudio or Ofono problem. And maybe it is no problem at all. Engelbert |
|
Thanks for the report - I've opened a case with Cypress. |
|
Having problems with SCO on a non-Raspberry Pi CYW43455 used in the recently discontinued Samsung Artik 710 module. Dunno if that helps any, but mentioning it just in case. Thanks for looking into this! Also, maybe some Pi 3 B+'s use the CYW43455 as well, at least if this press release is accurate: https://www.cypress.com/news/cypress-delivers-robust-wireless-connectivity-raspberry-pi-3-model-b-iot-single-board-computer |
|
We've never made a secret of the fact that all 3B+s use CYW43455. |
|
I just went ahead and tried that hcitool command on the CYW43455 and at least for me it got the audio to play. It clips on the end, but that's probably a separate issue (and I'm using bluealsa, so that could even be involved). However, this is not a Pi, so my results are not that relevant. I have a Pi 3 (older, non-B+) and Pi 4 and I plan on giving those a try when I can. EDIT for offtopic info: EDIT 2 offtopic: Opened a bluealsa bug, here, and the truncation was resolved with a bluealsa source modification: arkq/bluez-alsa#260 |
|
Secret or not. I was expecting to have a proper working chip for WLAN and BLUETOOTH on my Pi 3 which is not the case and in addition to this people reporting several other issues, related to this ticket here. |
|
FWIW, Cypress have acknowledged my request and forwarded it to the right person, but nothing more so far. |
|
Cypress think that the required SCO audio routing is already enabled in the firmware. They would like a log of the HCI traffic to the modem, which you can capture by running "sudo btmon -w btmon.cap" somewhere, ideally before you pair the device. After pairing, connect to it and attempt to play something short - I use piano2.wav from https://www.kozco.com/tech/soundtests.html - then run the hcitool cmd line and try again. After successful playback you can Ctrl-C the btmon command and upload the resulting capture somewhere - it was about 500kB for me. |
pelwell
added
the
Close within 30 days
|
Without HCI logs and/or a detailed description of the equipment and steps involved to reproduce the problem there is little we can do. Will close if no response in 30 days. |
|
Hello, |
|
Thank you - that's very helpful, and it's been forwarded to Cypress. |
pelwell
removed
Close within 30 days
|
@aurelihein I have audio playing over HSP/HFP now. In order for it to work properly I had to follow this guide: https://hackaday.io/project/165208-an-old-rotary-phone-as-bluetooth-set/log/162491-setting-up-the-bluetooth I started from a clean Raspbian install. Pairing and audio device selection can be done using the standard Raspbian Bluetooth tool (but note that starting pulseaudio will require the audio device is reselected, and I found I usually had to do it twice for it to work (there is a beep on connection, and I only got that on the second attempt). There are one or two steps missing from the guide:
If you don't edit default.pa it will use a2dp. If you don't patch pulseaudio with the correct mtu size it will sound strangely slowed down. If you don't start pulseaudio then when you play a sound it will try, then switch back to another output (HDMI for me). Note that this assumes you are running Raspbian, which has the magic hcitool command in /usr/bin/bthelper. Without that (and if the headset has been powered off since it was last run) you'll get no sound. |
|
Nope it does not work ! They are talking about Rpi zero ! |
|
I was testing on a convenient 3B+ which runs the same firmware on the same hardware. The crucial difference is that the 3B+ doesn't have a MAC address from the new dc:a6:32 OUI. The bthelper command needs to be updated to also recognise the new OUI and apply the same patch. An offline task is then to figure out why the HCI cmd is necessary, given that according to Cypress this should be the default. Try replacing the hciconfig ... grep ... line with: |
The bthelper script uses the OUI of the BDADDR (Bluetooth MAC address) to determine whether or not to run on a Bluetooth interface. Pi 4s have BDADDRs from a new OUI range (DC:A6:32:...), meaning that the "is it a Pi's on-board BT interface" test must be amended to include that as a possibility. See: raspberrypi/linux#2229 (comment) Signed-off-by: Phil Elwell <[email protected]>
The bthelper script uses the OUI of the BDADDR (Bluetooth MAC address) to determine whether or not to run on a Bluetooth interface. Pi 4s have BDADDRs from a new OUI range (DC:A6:32:...), meaning that the "is it a Pi's on-board BT interface" test must be amended to include that as a possibility. See: raspberrypi/linux#2229 (comment) Signed-off-by: Phil Elwell <[email protected]>
|
Forget my previous post and try this instead:
If this works for you then it shows there's nothing fundamentally wrong with the Bluetooth modem and its HSP handling. |
pelwell
added
the
Waiting for external input
|
To summarise my findings so far:
It isn't clear to me why anyone would want to use HSP for output when A2DP is available, which leads me to ask: |
|
Anyone know how to get this working as doesn't seem to be. Also if you want HSP then if *imtu should be 48/60/64? Confused.com but in the latest 2020-02-05 a bluetooth speaker/mic does not seem to work? Im PA11.0 MTA is now set in the kernel for PA.
So the kernel should have a MTU config of 64? There are a ton of devices that use HSP and since 1.6 HSP has been wideband audio it was just pulseaudio and settings that make HSP bad not HSP. I am not even sure if PA12 works with HSF/HSP as even with a bluetoothdongle/headset I can not switch profile. Seems Arch and Ubuntu are the same and maybe its just me but PA12/Bluetooth seems to be broken for HSF/HSP Also if you go the bluealsa route for some reason bluealsa is compiled with
So disabling internal bluealsa support which would seem contary in terms of bloat to the rational of opting for bluealsa |
Thank you @bluetiger9 and @kp339 ---- With your clues I was able to solve the metallic garbled noises by recompiling pulseaudio --- thanks so much! However I seem to be stuck on the next step - getting echo cancellation to work. The problem is that I can place calls and hear the other call participant clearly as well as speak, but I just cannot get the echo cancellation module to work I have tried these combos to no avail:
What happens is that I place the call, the conversation starts, and the other call participant has a devil of a time in the call because he/she can hear himself/herself. No doubt it is because of echo from the other participant speaking, getting played out of my pi's speaker, then picked up by my pi's microphone, and then fed back through the call. First I tried putting this in /etc/pulse/default.pa But that didn't work at all. Then, instead of putting that line inside the file, tried to manually load the echo cancel module on the shell: which just seems to crash pulseaudio every time. You can see the results of pulseaudio -v -v -v below --- the last two lines show the attempted load and "Illegal Instruction" and then pulseaudio quits. This happens on both Buster and Stretch, and happens whether or not I use the sudo apt-get install pulseaudio pulseaudio-module-bluetooth -y command to get a "standard" version of pulse audio, or if I compile my own version of pulseaudio (to solve for metallic / robotic / garbled noises. |
|
Just went through this process (loosely following this guide) on an RPi 3B+, no bluetooth dongle, all onboard kit with wifi enabled. I needed to make the changes suggested above by @kp339 (MTU from 48->64) in order to significantly reduce the garbled sound, which works a treat. (Even with the auto_detect_mtu module parameter specified.) As the codebase has moved on from 11.1 -> 14.2, I've included an updated diff in case it helps others. diff --git a/src/modules/bluetooth/backend-native.c b/src/modules/bluetooth/backend-native.c
index 5ba743966..87b479e0c 100644
--- a/src/modules/bluetooth/backend-native.c
+++ b/src/modules/bluetooth/backend-native.c
@@ -194,8 +194,8 @@ static int sco_acquire_cb(pa_bluetooth_transport *t, bool optional, size_t *imtu
if (sock < 0)
goto fail;
- if (imtu) *imtu = 48;
- if (omtu) *omtu = 48;
+ if (imtu) *imtu = 64;
+ if (omtu) *omtu = 64;
if (t->device->autodetect_mtu) {
struct sco_options sco_opt;
diff --git a/src/modules/bluetooth/backend-ofono.c b/src/modules/bluetooth/backend-ofono.c
index d7a13efd0..2b4ba578c 100644
--- a/src/modules/bluetooth/backend-ofono.c
+++ b/src/modules/bluetooth/backend-ofono.c
@@ -269,9 +269,9 @@ static int hf_audio_agent_transport_acquire(pa_bluetooth_transport *t, bool opti
* made available to userspace by the Bluetooth kernel subsystem.
* Meanwhile the empiric value 48 will be used. */
if (imtu)
- *imtu = 48;
+ *imtu = 64;
if (omtu)
- *omtu = 48;
+ *omtu = 64;
err = socket_accept(card->fd);
if (err < 0) { |
Trying to use a bluetooth mic/speaker in a raspberry pi 3 (headless).
Hardware is Raspberry pi 3, firmware updated today, running raspbian also dist-upgraded today. Using bluez and pulseaudio (system service start mode).
No error messages seen in any log file.
Moreover, if I "down" ("hciadmin hci0 down") the internal raspberry bluetooth controller and use instead an external bluetooth controller connected in an usb port, both modes works correctly. Thus, problem seems related with the bluetooth device in raspberry card.
These are result from some related commands.
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.9.56-v7+ #1044 SMP Fri Oct 13 15:23:13 BST 2017 armv7l GNU/Linux
The text was updated successfully, but these errors were encountered: