Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RPi3 rev below 1.3] Occasional data loss when using bluetooth #476

Open
tmigone opened this issue Apr 24, 2020 · 11 comments
Open

[RPi3 rev below 1.3] Occasional data loss when using bluetooth #476

tmigone opened this issue Apr 24, 2020 · 11 comments

Comments

@tmigone
Copy link

tmigone commented Apr 24, 2020

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: raspberrypi/linux#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

  1. Remounted filesystem (mount -o remount,rw /)
  2. Edited baudrate in L22 of /usr/bin/btuart
  3. 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.

@tmigone
Copy link
Author

tmigone commented Apr 28, 2020

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.

@jellyfish-bot
Copy link

jellyfish-bot commented May 4, 2020

[alexgg] This issue has attached support thread https://jel.ly.fish/#/08688e98-861e-40ed-b3a1-0ec794c20356

@floion
Copy link
Collaborator

floion commented May 6, 2020

@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.

@floion
Copy link
Collaborator

floion commented May 6, 2020

Nevermind, it started appearing on my side also

@tmigone
Copy link
Author

tmigone commented May 6, 2020

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.

floion added a commit that referenced this issue May 8, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
@floion
Copy link
Collaborator

floion commented May 8, 2020

Should be fixed by #482

floion added a commit that referenced this issue May 8, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for the rpi
variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
floion added a commit that referenced this issue May 8, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for the rpi
variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
floion added a commit that referenced this issue May 8, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for the rpi
variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
floion added a commit that referenced this issue May 8, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for bt equipped
rpi variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
floion added a commit that referenced this issue May 9, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for bt equipped
rpi variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
@floion
Copy link
Collaborator

floion commented May 11, 2020

@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.

@tmigone
Copy link
Author

tmigone commented May 12, 2020

@floion is this after the fix in #482 ?

@salvq
Copy link

salvq commented Jun 2, 2020

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

@salvq
Copy link

salvq commented Jun 4, 2020

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.

balena-ci pushed a commit that referenced this issue Jun 28, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for bt equipped
rpi variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
balena-ci pushed a commit that referenced this issue Jul 28, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for bt equipped
rpi variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
balena-ci pushed a commit that referenced this issue Aug 24, 2020
The rpi3 v1.2 lacks hardware flow control for the uart used for
bluetooth. This fact coupled with an apparent change in scheduling
introduced between the 4.14 and 4.19 kernels made the SoC drop UART
data. See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-518654921

The workaround for this is therefore to lower the baudrate so that we
decrease the chance of having too much lost data.

This change here should be revisited when meta-raspberrypi switches to
kernel 5.x as I have tested the UART data drop on kernel 5.4.38 and did
notice way less data drop with the default 921600 baudrate and playing
audio over bt was a good experience overall with that kernel. (tested
using balenaSound v2.1.7).

Note that this change will only decrease the baudrate for bt equipped
rpi variants that lack hw flow control (i.e. just the rpi3 v1.2).
See for details:
https://github.com/raspberrypi/firmware/issues/
1150#issuecomment-603116313

Fixes: #476
Changelog-entry: Fix bluetooth data drop on rpi3 v1.2
Signed-off-by: Florin Sarbu <florin@balena.io>
@pjmartorell
Copy link

pjmartorell commented Jul 30, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants