balena-raspberrypi
balena-raspberrypi copied to clipboard
balena-os
[RPi3 rev below 1.3] Occasional data loss when using bluetooth
Raspberry Pi 3's before rev 1.3 have no HW flow control on the UART controlling the Bluetooth modem. This causes occasional data loss which is particularly noticeable when using Bluetooth for audio applications as it causes severe audio stuttering problems. Raspberry Pi 3B+ seems to be unaffected.
Description and more context can be found in this issue: https://github.com/raspberrypi/linux/issues/2264
Reducing the UART baud rate to 460800 lessens the problem significantly when compared to the default value of 921600. This is what I tested on:
Board: Raspberry Pi 3B rev1.2 with a 2.4A PSU OS: balenaOS v2.47.0+rev1 Application: balenaSound v2.1.7, streaming bluetooth audio from macOS
Test
- Remounted filesystem (
mount -o remount,rw /) - Edited baudrate in L22 of
/usr/bin/btuart - Reboot
Results
921600 (default) Two or three packets lost every second. Not usable.
115200 and 230400 Absolutely horrible performance. Much worse than the default 921600. Didn’t bother checking packet losses.
460800 Miles better! Run this for 20 minutes with an average of 2 packets lost per minute (couple of 6-8 bursts). Had a couple of 3/4 minute runs without packet losses. This is definitely “usable”, though it’s still a bit annoying when audio stutters for a moment because of a missed packet. Also it seems to get better with time, after a while of streaming I’m not getting any more bursts and only a packet gets lost every 3/4 minutes.
Testing Rasperry Pi 3 B 1.2 running balenaOS 2.38.0+rev1 works fine with default baudrate (921600). So something must have changed in between versions.
[alexgg] This issue has attached support thread https://jel.ly.fish/#/08688e98-861e-40ed-b3a1-0ec794c20356
@tmigone how reliably do you get this issue? I am running 2.47.0+rev1 and Spotify is happily playing over bt on rpi3 b v1.2 2015 using balena sound v2.1.7, no stuttering.
It's been 100% reliable for me :P Spotify uses WiFi so it works fine, maybe that is what was going on. nvm, you could be playing Spotify over BT... I was thinking of Spotify Connect.
@tmigone for me even lowering the baudrate as in the PR produces data loss making the balena Sound experience pretty terrible. So I would not go about lowering the baudrate.
I am using RPI ZERO W and pings gets very high while scanning Bluetooth (routine below looks for friendly name for given MAC address). Due to this scan wifi connection is being dropped. Reducing the UART baud rate to 460800 as indicated above did not help to reduce this issue.
I tried to simulate the issue by using PyBluez python library.
import time
import bluetooth
while True:
bluetooth.lookup_name('C4:D3:92:E6:F3:26', timeout=3)
time.sleep(10)
Every bluetooth scan, ping gets out of reasonable response, up to 3000ms which is bluetooth timeout scanning period. When there is known MAC address, ping is adequate for period of finding the friendly name from MAC address.
PING 192.168.1.204 (192.168.1.204) 56(84) bytes of data.
64 bytes from 192.168.1.204: icmp_seq=26 ttl=64 time=5.40 ms
64 bytes from 192.168.1.204: icmp_seq=27 ttl=64 time=5.18 ms
64 bytes from 192.168.1.204: icmp_seq=28 ttl=64 time=5.13 ms
64 bytes from 192.168.1.204: icmp_seq=29 ttl=64 time=6.09 ms
64 bytes from 192.168.1.204: icmp_seq=32 ttl=64 time=1995 ms
64 bytes from 192.168.1.204: icmp_seq=34 ttl=64 time=197 ms
64 bytes from 192.168.1.204: icmp_seq=35 ttl=64 time=5.15 ms
64 bytes from 192.168.1.204: icmp_seq=36 ttl=64 time=6.51 ms
64 bytes from 192.168.1.204: icmp_seq=37 ttl=64 time=1.95 ms
64 bytes from 192.168.1.204: icmp_seq=38 ttl=64 time=9.38 ms
64 bytes from 192.168.1.204: icmp_seq=39 ttl=64 time=5.15 ms
64 bytes from 192.168.1.204: icmp_seq=40 ttl=64 time=5.21 ms
64 bytes from 192.168.1.204: icmp_seq=41 ttl=64 time=5.29 ms
64 bytes from 192.168.1.204: icmp_seq=44 ttl=64 time=2814 ms
64 bytes from 192.168.1.204: icmp_seq=45 ttl=64 time=1774 ms
64 bytes from 192.168.1.204: icmp_seq=46 ttl=64 time=931 ms
64 bytes from 192.168.1.204: icmp_seq=47 ttl=64 time=4.89 ms
64 bytes from 192.168.1.204: icmp_seq=48 ttl=64 time=5.14 ms
64 bytes from 192.168.1.204: icmp_seq=49 ttl=64 time=5.20 ms
64 bytes from 192.168.1.204: icmp_seq=50 ttl=64 time=5.14 ms
64 bytes from 192.168.1.204: icmp_seq=51 ttl=64 time=5.18 ms
As far as I know, BT and WIFI shares the same aerial...
BT/Wireless Coexistence: The BRCM43430 chip actually contains two different chips internally, but using the same aerial, since they use the same frequencies. They are actually on different interfaces to the BCM2537, Wireless on SDIO, BT on UART. The aerial sharing does actually cause some issues.
I am very disappointment from Zero W, have not checked that deep in spec.
I have a Raspberry Pi 3B rev1.2 and I installed balena-cloud-balena-sound-raspberrypi3-64-2.80.3+rev1-v12.7.0.img and even decreasing the baudrate I couldn't almost not play anything via bluetooth. BTW, the link L22 you wrote is not a permalink and it's not pointing to the correct line.
Later I downgraded to balenaOS 2.38.0+rev1 and it works better but I still have the similar errors and the audio drops every few seconds:
30.07.21 21:34:13 (+0200) audio E: [bluetooth] a2dp-codec-sbc.c: SBC decoding error (-3)
30.07.21 21:34:13 (+0200) audio E: [bluetooth] module-bluez5-device.c: Decoding error
When I disconnect and connect again to the device the issue is fixed temporarily but after a few seconds it fails again.
