Hello,
I'm testing with streaming music using a2dp over bluetooth on the Pi3. When Wifi is enabled, I get constant buffer underruns wit Pulseaudio (Blueman shows a downstream of around 34kB/s). As soon as I disable the Wifi interface (ifdown wlan0), the audio starts to play normally and the downstream is around 42kB/s (which is correct high quality stereo audio if I see http://soundexpert.org/news/-/blogs/bluetooth-audio-quality-a2dp).
Also tried making the buffer much larger, changing resampling type, realtime-scheduling etc. Also tried latest Pulseaudio, no difference. Seems like it is a Raspberry problem.
First thought it was because the Wifi and Bluetooth both use UART, but the is not true (and would be too slow if Wifi was over the 921600 baud if I see it correctly). They still share the same chip (BCM43438). Is there a known reason why I (and also heard others) have this problem?
I've been having the exact same issue. Disabling WLAN0 fixed the audio issues. However, I would very much like to be able to use the wifi...
Same is here. Took me 3 days, 2 distros to figure out it was the build in WiFi. Same error appears when i use a WiFi stick direktly at the USB Ports. When i use a USB connection cable with the USB stick everything works fine. So i simply think it comes from the build in antenna that the two 2.4 GHz services interfer each other. :-/
I was able to get A2DP to work by disabling the on-board wifi and using a Wi-Pi USB adapter, without any extension cable.
This brings up a rather interesting question: Does the on-board WiFi chip support Bluetooth co-existence, does the driver support this, and does it work correctly? Based on what I've seen from multiple sources, there's considerably better latency when you either disable the on-board WiFi or disable the on-board Bluetooth and use a USB adapter instead, and that sounds to me like either the on-board chip doesn't correctly implement BT co-existence, or the driver doesn't properly support it.
The BCM43438 has a co-existence interface between the WiFi and Bluetooth interfaces - no software support is required.
@Ferroin From my experience I would say /fundamentally/ yes it does, although I'm not an authoritative source and I do not demand much on the Bluetooth side.... Whilst developing Bluetooth LE central and peripheral applications on a Pi 3 I run a VNC X session, 2x SSH sessions and have NFS share mounted all via WiFi and all are ok.
+1 on this, as I've just discovered tonight. Took wlan0 down and the audio played just fine. Has anyone gotten any new word since August on what's going on here and if there's a fix?
+1 me too, "ifdown wlan0" and pulseaudio streams fine via a2dp
+1, just updated today, using an Anker Sound Core bluetooth speaker. Plays beautifully if I turn off wifi, but that's a pretty big workaround. It's annoying but workable for this project (
+1 that gave me headaches finding this problem out !
I needed WiFi so I just:
1) Use a USB dongle as WiFi adapter
2) Disable onboard WiFi adapter in /etc/network/interfaces
No more sound problems.
I'm excited to see any progress on this, but as a reminder, you can Subscribe to this thread and add a reaction to the original post. It is not recommended to post a response of +1.
Agreed that no WiFi is crippling to the base Pi3. Adding a usb dongle defeats one of the big gains w/ the Pi3 of onboard WiFi/BT. :-(
I have also tested the behavior and facing same issue as reported here. Planning to add additional USB WiFi adapter to overcome the problem. Hope pi would support second WiFi without much problems.
I guess the Zero W will suffer from the same issues regarding Bluetooth and WLAN, as its using the same chip?
Using USB-devices as workarounds ain't that easy with the Zero W, though.
Is this happening to everyones Raspberry Pi? How is the music being played? (Pi hat DACs, sound cards, BCM?) What are you using the Wifi for?
Because, I haven't had any issues with my Pi3
Only an issue when both are going. WiFi actively transmitting and then try to use Bluetooth. Bluetooth + LAN is no problem. So most people and applications won't see the issue.
I have added secondary WiFi receiver and made it primary and using embedded WiFi as bluetooth receiver. This is a cheapest way to get this working.
Bluetooth + LAN is no problem.
Please show me the LAN-port on the Pi0W.
Has anyone tried renicing pulseaudio to have a higher priority?
Yes, I tried with with higher priority with no discernible difference in the outcome.
Hi,
Can you please let me know a workable-configuration if you have one for
the above problem i.e Wifi - needed, Bluetooth Speaker pairing in A2DP
mode.
From your profile, It looks like you have extensively played around in that
area.
Thanks.
Cheers,
Pradeep
http://pradeepclicks.com/
On Mon, Mar 6, 2017 at 9:29 PM, Brett Reinhard notifications@github.com
wrote:
Has anyone tried renicing pulseaudio to have a higher priority?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-284439625,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADb1rV3_oFd2_qM8-2yHoDdLGeFK3d5dks5rjC1ngaJpZM4IExoX
.
I am also trying to solve this problem. The choppiness seems to change a bit among different BT speakers/headphones, but it's still there using a WiFi dongle and disabling the onboard WiFi. Even using a BT dongle, the choppiness is still there while playing a local mp3 or using Pithos (Pandora). I also used a lower bitrate mp3 file, and the choppiness improved.
I downloaded a couple of sample files from 16 to 64kbps and played them using VLC on RPi3. I am running pulseaudio and connecting to some cheap bluetooth earbuds.
http://www.digitalprosound.com/Htm/WebAudio/2000/Oct/MP3bitrates3.htm
With only background WiFi activity, each file played, but did exhibit some choppiness with the increasing bitrate. Then, I ran an apt-get update and while it was running played the 16k file. Very choppy. Same for the others. In fact, the wifi activity had more of an effect than the bitrate of the file.
Now attach a WiFi dongle and disable the onboard Wifi (sudo ifdown wlan0). Try again.
All files completely smooth. What about while performing a download over Wifi? Also smooth at 64kbps.
Running Pithos(Pandora)? Smooth. This was not the case last night, so I am not convinced I have a solid solution.
I experience the same issue.
I resolved it by using a Bluetooth dongle wich is a complete success.
Plugable Technologies USB-BT4LE
Still not happy with this though, what is the point of having features that cannot be used.
One thing you have to make sure is that you turn off bluetooth scanning (scan off) while in the bluetoothctl prompt. That resolved my issue and I was able to stream nicely with a Pi Zero W, Pi3, using the built-in wifi/BT and Pi Zero + redbear IoT PiHat.
@Michiman : I'm 100% sure that i tried it without scanning on at the same time. still had the issue. I'm using rpi3 though.
+1
same here it's definitely the combination of onboard wifi + bluetooth.
Setup: pi zero w + phat dac
Onboard bluetooth+wifi enable -> audio stutters very badly
onboard wifi disabled -> audio plays perfectly without stuttering
I guess i need to start investigating how this all works on a low level- which forms a nice challenge to learn this properly
I also had terrible sound issues trying to stream audio using a2dp tutorials based on pulseaudio.
I tried suggestions of tuning buffer sizes and disabling internal WLAN.
Sound quality improved greatly, but still not to the point that I would use this as a real listening device - at best I would get a pop or stutter every few seconds.
I found another github project that overcomes the issue by avoiding pulseaudio entirely:
https://github.com/lukasjapan/bt-speaker
After disabling the internal WLAN, audio is quite reasonable using that method, and no need to login at boot (I have it running in the background of my retropie image).
@maklotski , We have already established that the issue is caused when both Wi-Fi and Bluetooth are on at the same time. Yes if you do not need WiFi then the solution is to disable this. However I need to stream audio from online so WiFi is critical. I'm surprised that RPF has not released any useful information on this issue to date.
We have released all the useful information we have, i.e. not very much. Cypress (was Broadcom) have two parallel driver stacks - dhd and brcmfmac. They are supposedly close to finishing an updated dhd driver which improves coexistence, but a) it is still being tested and b) we use brcmfmac. As soon as there is an improved brcmfmac driver we will push it out.
Simply adding +1
to this issue is of no use. It just makes the comments list longer for no reason. As soon as we have any information it will be posted.
+1 to continue putting this on the radar and hopefully escalating priority
for a fix
This github thread will be updated when information relevant to the issue is available. We are somewhat dependent on Broadcom (now Cypress) providing driver updates as the coexistence support on-chip is a function of the chip's firmware or firmware setup.
Degrading the signal-to-noise ratio of the thread with spammy responses is just irritating. Comments that do not offer anything to the discussion surrounding investigation or resolution of the issue are likely to be summarily deleted.
I wrote a little script to use inotify to switch on and off wlan0 if bluetooth connects/disconnect. Ok it is
a workaround but i can live with it.
`#!/bin/bash
while true
do
RES=inotifywait -q -e CREATE,DELETE /dev/input/
case "$RES" in
"/dev/input/ DELETE event1")
ifconfig wlan0 up
;;
"/dev/input/ CREATE event1")
ifconfig wlan0 down
;;
esac
done &
`
So here's the work(alltheway)around I'd like to share at the expense of being laughed at.
Run pacat /dev/zero
in the background
Now play some audio and after the crackling stops +-30 seconds then play some more audio and enjoy the clear playback until you stop pacat.
If you worried about all the zeros flying over bluetooth then maybe consider installing "pv" with:
sudo apt-get install pv
Run the following in the background instead cat /dev/zero | pv -qL 2k | pacat
to limit the zeros to a certain bitrate.
Would like to know how this works for you.
Interesting, all. I've been working on a headless Pi Zero/W -- No X11. And I can have two/three ssh shells going over wifi, and Bluetooth is as clean as it can be. I did notice that excessive polling of the Bluetooth device, (ie getting Bluetooth info) causes stutter. Have you tried just booting to cli?
Well, I just realized that the following comment wasn't really helpful without context. Sorry, been banging away at the keyboard all night ----
1 - Pi Zero/W and Pi 3 identical in terms of Bluetooth/Wifi, at least as far as the kernel is concerned.
2 - Running Jessie Lite - recently updated, and kernel 4.9.29+
3 - Running NetBeans on desktop and remote Debugging on Pi.
4 - Stress testing Frame rates with a TFT display --- really cranking that SPI bus.
5 - Polling input events for touch screen and dumping results to stderr, which gets piped to NetBeans -- testing jitter on touchscreen
6 - Running mpg123_to_out123 example program from mpg123 tarball over Bluetooth playing Billy Joel's "An Innocent Man" from SD card.
7 - No X11 in sight.
Running as smooth as a pie, raspberry flavored. Been doing this soo long I hum Billy Joel in my sleep.
Have noticed that that forcing a query for Bluetooth connection status made things bad.
Suggest eliminating as much "other" code as possible.
Hi,
there is definitely a serious problem with the PI (Zero W) Bluetooth.
I moved a python script that detects phones via bluetooth from a C.H.I.P to a Pi Zero W.
The result was crazy, it jammed my whole Home Wifi when Bluetooth was accessed :-(
The script uses the following command to detect if a phone is in range:
result = bluetooth.lookup_name(mac, timeout=5)
I run this in a loop with two phones. The loop starts every 15 seconds and tests both phones.
I first notified that a) SSH over Wifi was unresponsive sometimes and b) my WiFi LED Light were not responding sometimes after setting up the Pi Zero W.
Strange, so i tried to ping the Wifi Lights, result: Timeouts for about 5 Seconds every 15 seconds.
Then I tried to ping the PI Zero W: Ping times of about 2000-4000ms during those 5 second windows, sometimes also even timeouts.
So I disabled the script running the bluetooth detection: Anything was fine.
Re-starting the script: The timeouts occurred again.
This is crazy! The bluetooth scanning for the phones (It's basically a "are you there?" to a paired bluetooth device) basically breaks my whole Home Wifi.
I know that Bluetooth and Wifi are on the same frequency. But Bluetooth is standardized to use extensive frequency hopping to prevent just such interference. Not so on the Pi Zero W?
It's definitely reproducible, just try the python script below.
My best guess about the reason: The bluetooth radio disturbs the Wifi, not the other way around. The reason could be a problem in the bluetooth stack regarding frequency hopping. This would also explain the reported bluetooth audio problems: when bluetooth does remain on one frequency, the wifi is more likely to disturb it's signal.
However, I might be wrong, I know WiFi pretty well as I did my PhD on a topic dealing with the Phy Layer of Wiifi, but I am no expert on the Bluetooth Phy.
A short python test script that reproduces the problem. Just ping the Pi while running it.
import time
import bluetooth
mac = "00:00:00:00:00:00"
while True:
print("Search Bluetooth for %s ..." % mac)
try:
result = bluetooth.lookup_name(mac, timeout=5)
except bluetooth.btcommon.BluetoothError as e:
print("\nERORR: Bluetooth request failed, error: %s" % e)
print("Result: %s is: %s" % (mac, result))
time.sleep(15)
Tomorrow, (Monday evening EST), if you want, I'll post a youtube showing how well it works. However, just double/triple confirming (just 5 minutes ago) ---- the only problems occur during "Discoverable" and "Scanning". If you make your device non-discoverable and not actively scanning (discovering) WiFi and Bluetooth work just fine together on a Pi Zero W. I get s steady 4-5 ms ping over WiFi while connected via Bluetooth and ssh. Need to figure out how to record sound for a youtube video, but I can plainly hear it jitter free.
FWIW - I'm working on a Bluetooth Audio application, so this really does concern me. In my app, I was polling the connected device's info to get RSSI, etc. I had to take the polling out, because of the problems already noticed by soo many people here.
Unless you are in control of all the apps in your session that might do a poll (D-Bus) on the Bluetooth connection, you can't rule them out as being complicit in the problems. I'm not running X11 - therefore I'm much closer to the hardware and what happens. Granted PulseAudio is still a "blackbox", but aside from that, I'm basically in control of the whole deal and it does work quite well.
Now -- I'm not saying that the firmware doesn't have problems, but in reality, the apps should be better behaved.
Hey,
I'd be really interested in a youtube video if you have time :)
I'm also using a Pi Zero W, but when I disable the Wifi it sill stutters a little...
Hi, just a note - my Zero W suffers from the same problem - skipping BT audio when streaming by wifi - even for 9.1/Stretch release of Raspbian
Cypress are hoping to improve the "coexistence" between WiFi and BT, but they've been focusing on some WiFi stability issues first.
Hi, any updates on this?
Starting with the most recent Raspbian Stretch image, run:
sudo apt-get update
sudo apt-get install bluez bluez-firmware
This will pull in a new Bluetooth firmware and an updated BlueZ that, together, should improve the WiFi and Bluetooth coexistence.
While you are at it, get the latest kernel for improved Bluetooth reliability:
sudo apt-get install raspberrypi-bootloader raspberrypi-kernel
I'd love to see a side by side video of the performance of BT/WiFi
together. If someone hasn't made one, I'll have to work on it.
On Nov 7, 2017 12:15 PM, "Phil Elwell" notifications@github.com wrote:
While you are at it, get the latest kernel for improved Bluetooth
reliability:sudo apt-get install raspberrypi-bootloader raspberrypi-kernel
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-342554756,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZCYY6u0Q45M19rAdGFM0WP4q6VXP0Zeks5s0JBOgaJpZM4IExoX
.
@pelwell I upgraded bluez bluez-firmware raspberrypi-bootloader raspberrypi-kernel to the last version, as advised by you.
However I'm still facing issue with sound streamed over bluetooth to the raspberry zero W when wifi is up. If I shutdown wifi (sudo iwconfig wlan0 txpower off
), it works well and no more crackling happens.
Please let me know if I can be of any help.
I'm using bt-speaker. Related issue reported here : https://github.com/lukasjapan/bt-speaker/issues/4
Are you saying you saw no improvement?
unfortunately, no improvement :(
@pelwell Just for you to know, here's installed versions :
bluez 5.43-2+rpt2+deb9u2
bluez-firmware 1.2-3+rpt1
raspberrypi-kernel 1.20171029-1
raspberrypi-bootloader 1.20171029-1
Is anyone having this same type of issue with PS3 controllers (via bluetooth) using Retropie with wifi enabled on the rpi 3? I have what seems to be random interference where sometimes the controllers work fine and sometimes it's as though I didn't press anything at all. Makes it a bit difficult to play games that way!
Today I updated a Pi Zero W to all the latest and can confirm the problem still exists.
pi@raspberrypi:~ $ dpkg -l | grep -i bluetooth
ii bluealsa 0.6 armhf Bluetooth ALSA Audio backend
ii bluez 5.43-2+rpt2+deb9u2 armhf Bluetooth tools and daemons
ii bluez-firmware 1.2-3+rpt2 all Firmware for Bluetooth devices
ii libbluetooth3:armhf 5.43-2+rpt2+deb9u2 armhf Library to use the BlueZ Linux Bluetooth stack
ii lxplug-bluetooth 0.4 armhf Bluetooth plugin for lxpanel
ii pi-bluetooth 0.1.6 armhf Raspberry Pi 3 bluetooth
ii pulseaudio-module-bluetooth 10.0-1+deb9u1 armhf Bluetooth module for PulseAudio sound server
The BCM43438 seems to have problems with multiple connections, either with BT+WiFi or with two BT connections:
When switching off WiFi (ifconfig wlan0 down
or dtparam=pi3-disable-wifi
) Bluetooth A2DP audio works quite fine. However when two devices are connected, the audio begins to stutter badly.
With an external USB Bluetooth adapter, multiple devices can connect via A2DP and stream audio, event simultaneously.
So I assume, this is a limitation of the chip, not a software thing... (But I'd love to be proven wrong in a future kernel update)
Make sure you are running with the latest BT firmware (sudo apt-get update; sudo apt-get install bluez-firmware
) - there have been some improvements.
I last did that 2 days ago, has it changed since then?
-Ron
From: Phil Elwell notifications@github.com
Sent: Wednesday, January 24, 2018 5:32 AM
To: raspberrypi/linux
Cc: Ron Kuper; Manual
Subject: [External] Re: [raspberrypi/linux] Pi3 bluetooth audio stutters with Wifi enabled (#1402)
Make sure you are running with the latest BT firmware (sudo apt-get update; sudo apt-get install bluez-firmware) - there have been some improvements.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/raspberrypi/linux/issues/1402#issuecomment-360088465, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AC8KdHhcuhMFBE5j42nTMhwc5NJTfxocks5tNwahgaJpZM4IExoX.
No - that will be the latest (1.2-3+rpt1).
Thanks! In the meantime I bought a USB wifi dongle as a workaround.
Does anyone happen to know if the chipset driver is supposed to (in theory) take steps to avoid RF interference between these 2 radios?
-Ron
From: Phil Elwell notifications@github.com
Sent: Wednesday, January 24, 2018 7:20 AM
To: raspberrypi/linux
Cc: Ron Kuper; Manual
Subject: [External] Re: [raspberrypi/linux] Pi3 bluetooth audio stutters with Wifi enabled (#1402)
No - that will be the latest (1.2-3+rpt1).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/raspberrypi/linux/issues/1402#issuecomment-360113610, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AC8KdIfVVwDf2lOlcGQTppx5A0jxxzvbks5tNyAWgaJpZM4IExoX.
It is supposed to (there is a coexistence channel between what is essentially two separate devices in the same package), and this firmware is a significant improvement over the original shipping firmware, but sharing an aerial seems to be a challenge.
@spalthammer wrote a script which would serve as a nice workaround:
I wrote a little script to use inotify to switch on and off wlan0 if bluetooth connects/disconnect. Ok it is
a workaround but i can live with it.
`#!/bin/bash
while true
do
RES=inotifywait -q -e CREATE,DELETE /dev/input/
case "$RES" in
"/dev/input/ DELETE event1")
ifconfig wlan0 up
;;
"/dev/input/ CREATE event1")
ifconfig wlan0 down
;;
esac
done &
`
Can someone please explain to a newbie how to get this script implemented? This would work great for me since I don't need wifi while bluetooth is playing. However I still want the ability to use ssh/vnc for my Pi3 when the BT device disconnects.
@lexanix
install inotify
cmd: sudo apt-get install inotify-tools
cp inotify.txt to /etc/inet.d/inotify ( rename from inotify.txt to inotify ! )
make it executable
cmd: sudo chmod u+x /etc/init.d/inotify
create symlinks to start script at boot
cmd: sudo update-rc.d inotify defaults
Hope this helps.
@spalthammer thank you for your response! unfortunately this seems to be not working for me. I did everything you said but nothing is happening. inotify-tools is up to date on my Pi3.
what I tried to do:
(I obviously changed the typo of "inet.d" to init.d)
-made it executable with chmod +x only since u+x didn't work
-tried to execute the script directly from the terminal (without reboot) which it did since I added a line to return an echo and it worked
-made it boot at start from /etc/rc.local
However, the wifi still remains ON when I connect my phone via bluetooth...
I'm running the latest version of Raspbian. My phone streams music to the Pi over BT which then outputs as a FM signal at the GPIO. During that time I don't need any wifi enabled since the music starts stuttering. However, to still be able to reconnect to my Pi with SSH/VNC after I disabled the wifi I made a little script "sudo ifconfig wlan0 up" which automatically enables it again after I cut the power and let it reboot. This seems to be working for now but I would like to have the much more elegant inotify script running until we know what's wrong with our BT+WiFi chipset.
@lexanix,
sorry for the typo.
sudo chmod u+x /etc/init.d/inotify
should work. Please be sure that /etc/init.d/inotify is owned and executeable by root.
If you have more than one input device connected, lets say keyboard, mouse and usb soundcard, the number for the input device may be different. In the script i'm waiting for events on input1, which fits my setup. Please stop the script with
sudo killall -9 inotify
and run
sudo inotifywait -q -e CREATE,DELETE /dev/input
Connect to the bluetooth device and write down the number for your input device. Change the script and restart.
I've double checked the script. Even if it's not perfect, it works as expected.
Regards
BT connection is not stable during A2DP playback. BT often gets disconnected and requires a system reboot to recover.
can you give the solution.
@spalthammer great ! your script works as expected
perfect solution for me (Zero W with speaker phat; now using both internal Bluetooth and WiFi interfaces alternating)
no more cracks while music playing :-)
Will this be better with the new Raspberry Pi 3 B+?
@spalthammer
Thanks for the great workaround. It's just what I need.
Even though I have just one Bluetooth connection, I get the following when I do
root@Ipad2GMA:/etc/init.d# sudo inotifywait -q -e CREATE,DELETE /dev/input
/dev/input/ CREATE event0
So, as you suggested, I edited inotify and changed from event1 to event0. It works great now!
But, I worry about that changing. If I only have the single BT connection, will it always be event0?
Thanks!
@davthomaspilot,
the number X in eventX depends on the number of input devices not on the number of bluetooth connections. So unless you change your hardware setup, say if you do not add another input device such as an USB sound card or a keyboard, the number should not change. If you want to know more about you connected input devices the command:
cat /proc/bus/input/devices
will give you an overview.
Ragards.
This workaround worked great for me! But, it seems like I no longer need it, for some reason--
I just got another pi zero w. Downloaded the jessie stretch image and did the update, upgrade thing. I'm using a pHat DAC and the Bluetooth setup instructions from here:
[https://www.sigmdel.ca/michel/ha/rpi/bluetooth_01_en.html]
Is it possible there's a fix I picked up in the upgrade or update? Or, maybe my new rpi has a hardware fix?
I'm cloning the image on my pi that doesn't stutter and going to try it on the one that needed spalthammer's workaround. And, I'll try the image that's in the stuttering rpi on the new hardware, and disable the workaround to see if the new hardware stutters with that image.
I've found I only have the issue if I leave bluetoothctl running. On both the new hardware/"software" and old, I don't get any interruption of the bluetooth A2DP stream unless I'm in bluetoothctl.
This is stretch-lite, without pulse-audio. Maybe that's significant.
@pelwell , Any idea if this is possibly resolved as part of the new WiFi firmware from cypress as mentioned here?
https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=208090
regards,
@StudentSA Doesn't seem like it. At least not entirely. I'm experiencing this issue on a Zero W running 2018-04-18-raspbian-stretch-lite.
bluez 5.43-2+rpt2+ armhf
bluez-firmware 1.2-3+rpt5 all
raspberrypi-bootloader 1.20180417-1 armhf
raspberrypi-kernel 1.20180417-1 armhf
Possibly one of those issues that will never be fixed...
I decided to dig into the drivers a little. Reading through the code gave me some insight into some of the module parameters that are supported, and with some experimentation and a shotgun approach, I seem to have gotten bluetooth + wifi working perfectly in conjunction with each other.
I was able to perform a speedtest from the pi over wifi, while my phone played A2DP audio through the pi, and I didn't get a single glitch.
I created a file /etc/modules.d/bt-wifi-fix.conf
options brcmfmac fcmode=2
options brcmfmac feature_disable=0x96
#options brcmfmac debug=0x00000004
debug=0x00000004
enables info level logging, which isn't really necessary.
fcmode=2
appears to enable some kind of hardware flow control, which seemed to make things a little better, but still not great.
feature_disable=0x96
is the option that seemed to really fix it. I'm not certain, but I _think_ 0x96
is trying to disable all optional features, hence why I said 'shotgun approach' above. With some patience it's probably possible to narrow this down to a small subset of features.
So far this has worked perfectly for me - I'll report back if I am able to narrow things down further.
EDIT: I get a little bit of glitching when I first start a stream, but absolutely nothing that seems dependent on whether I'm using wifi or not.
That's a great data point, thanks for looking in to it and please keep us updated on any further progress.
@pelwell Phil, did you see this? Might be worth reporting back to Cypress.
That does seem very simple - if Cypress are happy with it and it's so effective we can make those the defaults for Pi kernels.
Is it sufficient to simply create /etc/modules.d/bt-wifi-fix.conf with the contents you indicated? Or, must I change something else to get it to take effect?
Just create the file as described and reboot.
Ok, I googled and found stuff for /etc/modules-load.d, but not /etc/modules.d
I added the file on a Pi Zero W. I'll stream over bluetooth for a while, and see if I hear stutters while wifi connected.
Is there a way to check that bt-wifi-fix.conf got used, other than testing for "no hiccups?"
Thanks!
If you include options brcmfmac debug=0x00000004
(without the comment #
) then you should see some diagnostic output in the kernel log, as viewed by dmesg
.
Ok, I tried this:
dmesg | grep brcmfmac
[ 11.083290] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 11.103157] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[ 11.103836] usbcore: registered new interface driver brcmfmac
[ 11.563229] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[ 11.575677] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-10-23 03:47:14
[ 18.913833] brcmfmac: power management disabled
[ 27.484932] brcmfmac: power management disabled
So, do the
power management disabled
messages indicate the .conf is being picked up?
If not, is there something else I can grep for?
Tested on a ZeroW running a 4.14.41 kernel (custom OS) While many many times better, there are still some stuttering.....but almost tolerable.
I ran iperf3 back to my server while playing a2dp stream....the wifi was pushing
about 30MBit/s on iperf3.
Plans to test on a pi3 and pi3b+ (The 3b+ can already play nicely if the wifi is connected on 5Ghz channel)
@davthomaspilot I'm just trying this myself now, and the suggested file content looks correct, but although the directory name looked familiar it isn't present on my Raspbian system - /lib/modprobe.d
is the usual (and perhaps _correct_) place - so I suggest using the filename /lib/modprobe.d/bt-wifi-fix.conf
.
Start with the fcmode
and feature_disable
lines commented out and grab the output from dmesg | cut -c16- | grep brcmfmac
. Then uncomment one or both of them, reboot and compare the dmesg output (and streaming quality).
Thanks! I'll do that.
I'm hoping this helps more more than doing "iwconfig wlan0 power off" in /etc/rc.local.
With wifi power saving disabled, the streaming stutters only happen maybe once every minute or two. This is with nothing but an ssh session on the wifi.
It will take some "statistics" to see if there is a further improvement. I'll give it a try on the Pi Zero W.
Here's a diff comparing when the lines are commented versus not (using /lib/modprobe.d, NOT /etc/modules.d:
> brcmfmac: brcmf_feat_attach Features: 0x96, disable: 0x96
34c35,36
< brcmfmac: brcmf_fws_attach FWS queueing will be avoided
---
> brcmfmac: brcmf_fws_attach added MAC-OTHER
> brcmfmac: brcmf_fws_attach enabled bdcv2 tlv signaling [4f]
50,51d51
< brcmfmac: brcmf_p2p_add_vif adding vif "p2p-dev-wlan0" (type=10)
< brcmfmac: brcmf_add_if allocate non-netdev interface
54c54
< brcmfmac: brcmf_cfg80211_connect ie (d949d258), ie_len (22)
---
> brcmfmac: brcmf_cfg80211_connect ie (d96ac658), ie_len (22)
Testing streaming quality now...
It still stutters. It's really hard to tell if it's significantly better than what I have. A stutter once every minute or two.
Again, this is with wifi enabled, but virtually no wifi traffic.
Currently, my workaround is to disable wifi while bluetooth connected. I really don't care about stutters when I'm wifi connected, but it would be nice to to wifi connect without first having to disconnect Bluetooth.
Testing with a pi3B+ on a 2.4Ghz channel.
The parameter "options brcmfmac fcmode=2" crashes the wifi driver on a pi3B+ as soon as BT starts pushing data across the Bluetooth connection. Using a A2DP profile.
I'm running with just options brcmfmac feature_disable=0x96 on the pi3B+ and it's pretty stable, unless I push the wifi connection with iperf, then I do get some significant stuttering. No apparent side affects with this parameter when on a 5Ghz channel. Bluetooth is very stable in this case, and iperf3 pushing 120Mbit/s
So, not to throw a spanner in the works, but I honestly cannot reproduce this issue on the latest img of Stretch with the bluez firmware update and bluetoothctr update. I have 2 SD cards, one since I originally posted in April 2017 running Jessie and PulseAudio. and I created a 2nd SD card today running Stretch (9.4) and ALSA blue.
On Stretch, Things are perfect, I'm playing a online stream (i.e. using wifi) through my Bluetooth speaker 100%. The old card with Jessie still crackles badly when Wlan0 is up.
Credit to this dude who detailed a few tricks in the setup:
Michel
I tested using vlc so you need to specify which alsa device to use like so:
--aout=alsa --alsa-audio-device="bluealsa"
Please can someone try this from a fresh install and advise.
bluez 5.43-2+rpt2+deb9u2 armhf
bluez-firmware 1.2-3+rpt6 all
bluealsa 0.7 armhf
bluetoothctl: 5.49
raspberrypi-bootloader 1.20180417-1 armhf
raspberrypi-kernel 1.20180417-1 armhf
dont forget to start bluealsa after a reboot or autostart it: sudo systemctl enable bluealsa)
How did you installed bluetoothctl: 5.49? Hope not compiling from source code.
Yip, From source (as per the link shared) why the concern around this?
I just like to have updates by using repository, also to avoid packages needed only for building it. Where is the link located in your post?
There is actually a 5.50 version released 7 weeks ago. If you are going down this route it may be worth a try. But yes, we will need to wait for 5.49+ to get into the official apt-get flow.
I can confirm that it has no stutters with Bluez 5.50.
Cool. I'll look into what it would take to upgrade the Raspbian build.
Here are the steps:
sudo apt install libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev
Download the latest version of BlueZ source code.
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz
Uncompress the downloaded file.
tar -xf bluez-5.49.tar.xz && cd bluez-5.50/
Configure.
./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-experimental
Compile the source code.
make -j4
Install.
sudo make install
User needs to be added to the bluetooth group.
sudo adduser pi bluetooth
Dbus Bluetooth configuration file which was overwritten in the BlueZ installation needs to be restored.
sudo nano /etc/dbus-1/system.d/bluetooth.conf
Add this in <policy user="root">
section:
<allow send_interface="org.bluez.AlertAgent1"/>
<allow send_interface="org.bluez.ThermometerWatcher1"/>
<allow send_interface="org.bluez.HeartRateWatcher1"/>
<allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
and this afterwards:
<!-- allow users of bluetooth group to communicate -->
<policy group="bluetooth">
<allow send_destination="org.bluez"/>
</policy>
sudo reboot
@amilino Still not working for me. Still stuttering with wifi turned on, and when turned off. I've tried pretty much everything in this thread, even switched from an rpi b+ with a bt dongle to a rpi 3 b+ with onboard bluetooth and there's still stuttering.
Not quite stuttering, actually. It seems to get a chunk of data, play it back too fast with bits missing out of it, then sit and wait for the next chunk.
I have the same configuration as @StudentSA mentioned, except latest Bluez 5.50. I also followed this tutorial: https://gist.github.com/mill1000/74c7473ee3b4a5b13f6325e9994ff84c. I played the same songs which stuttered before and now they are working without problem.
@amilino Worked perfectly, thank you.
The only side effect of this tutorial is that audio is not playing if you connect Linux machine on RPI Bluetooth. If someone knows some better tutorial please give let me know.
Cypress have been looking into WiFi/BT interference and have come up with some new "NVRAM" file settings that they claim have "completely fixed the audio stuttering". The same settings can be used on the 43430 (3B, ZeroW) and 43455 (3B+).
Locate your "NVRAM" text file - it's in /lib/firmware/brcm/brcmfmac<dev>-sdio.txt
, where <dev>
is 43430 or 43455 respectively. Make a backup copy somewhere safe to make it easier to undo the changes (or recover from an error).
Open the file in a text editor, scroll down to the bottom (purely for neatness - these settings could probably go anywhere) and append the following:
# Experimental Bluetooth coexistence parameters from Cypress
btc_mode=1
btc_params8=0x4e20
btc_params1=0x7530
As it was explained to me, these settings collectively allow Bluetooth more airtime by allow WiFi to sleep for longer and reducing the maximum time Bluetooth can be made to wait.
Please report back your findings, whether positive or negative, to help us decide whether to make these the new default values.
Been following this thread with interest. I've been using a Pi ZeroW/Raspbian Lite to play internet streams through bluealsa to a bluetooth speaker using Mopidy. Up until today nothing in this thread has solved the stuttering problem.
bluez 5.50 - no difference
disabling WiFi and using a USB ethernet adaptor - some change but still stuttering every few minutes
Changing the NVRAM settings - seems perfect so far. I'm back to using WiFi and there is no stuttering in the bluetooth audio. Still using bluez 5.50. I'll report back if I do get any stuttering.
Positive results so far. I am also using Bluez 5.50 also. Board - RPi3
I've removed the previous modprobe parameters that were thrown up as a solution. So far no stuttering. Using iperf3, you can definitely see it stealing time from the wifi radio. But no stuttering, even when pushing extra data across.
While playing bluetooth,
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 22.8 MBytes 19.2 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 22.7 MBytes 19.1 Mbits/sec receiver
Stopping playback, and disconnecting speaker.
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 55.3 MBytes 46.4 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 54.9 MBytes 46.0 Mbits/sec receiver
Bluetooth disabled via dtoverlay
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 58.1 MBytes 48.8 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 57.0 MBytes 47.8 Mbits/sec receiver
Works for me raspi 3B, no stuttering, even moving an large file over wifi while playing audio (a2dp), but i'm seeing tons of
"Bluetooth: hci0: Frame reassembly failed (-84)" in milliseconds!
$ dmesg
[ 2331.758484] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2331.758689] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2331.758750] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2331.758833] Bluetooth: hci0: Frame reassembly failed (-84)
Been trying this for a few hours now. It's better than it was, but it's not perfect. I now get, often 20 to 30 minutes of continuous playback, but then the stuttering starts again and will not go away unitl I stop and restart the audio stream. Also my ssh session stalls for a moment when the stuttering starts. It's not audio buffering, because I've put logging in my player to tell me when it's buffering.
Maybe you should switch to RPi3 b+, I have no problems at all.
Maybe you should switch to RPi3 b+, I have no problems at all.
Not exactly the point though is it? The changes were said to "completely fix" the audio stuttering. I'm just reporting that that doesn't seem to be the case. The 3B+ uses a different chipset from the W, so perhaps the settings need tweaking a little.
Yes I agree, but looking at the issue subject it is related to RPi3. This discussion is anyway too long maybe it would be good to have new separate issue opened related to Pi W.
This solution works for a ZeroW as well. Been playing for well over 2 hours without issue.
I think the issues I've been experiencing on ZeroW are probably down to the Bluetooth not having quite the same range as the Bluetooth on my iMac. Putting the speaker closer to the Pi, I've been playing internet radio now for 4 hours without issues. I'll have to re-situate the Pi so the signal reaches the kitchen :)
Thanks for all the feedback, which suggest that these settings are at least a big improvement with no regressions. Feel free to chime in if your experiences are suggest otherwise, but I'm planning to make these the new defaults.
I can add one more observation with a positive outcome. I've been using both Bluetooth and Wi-Fi simultaneously on my ZeroW for about an hour now with no stuttering. Definitely a +1 on making this the new default.
Do you discuss here only the issue when rPi is used as a2dp source or also as a2dp sink?
I'm trying to use my rPi3 as a bluetooth sink (i.e. I try to play audio from my phone to my rPi), and stuttering is so intense, that you barely recognize played songs. Wi-fi is not used. I tried with external BT adapter - no luck. However, with different bt adapter stuttering was different (like if different buffer size was used).
Should I report a different issue?
@edio I've been using the RPi ZeroW as the sink, streaming audio from my phone to the RPi over Bluetooth. Until yesterday, I too had horrible stuttering, but the most recently suggested solution seems to have solved it.
Solution presented by @paul-1 works for me, on Pi 3+ board. I can use Wi-Fi normally and enjoy good BT audio stream
Hello,
does anyone have any idea how to use the NVRAM solution on a Libreelec system with a read-only squashFS system? As I understand it, it is read-only because the next distribution overwrites the system files.
@bwims
RPi3:
mkdir /storage/.config/firmware/brcm
cp /usr/lib/firmware/brcm/brcmfmac43430-sdio.txt /storage/.config/firmware/brcm
RPi3+:
mkdir /storage/.config/firmware/brcm
cp /usr/lib/firmware/brcm/brcmfmac43455-sdio.txt /storage/.config/firmware/brcm
Now edit the file in /storage/.config/firmware/brcm
and reboot.
Or you can use a recent LibreELEC 9.0 test build with Kodi 18 which includes this fix already: https://forum.kodi.tv/showthread.php?tid=298461
Does anyone in this thread still have occasional dropouts after the fix applied? It's not as terrible as stuttering I had initially, but still bluetooth sink is pretty unusable for me, as every couple of seconds I have bursts of clicks, roughly each one corresponding to series of records in pulseudio output
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-3)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-3)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
and from bluez I get
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-84)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-90)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-84)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-84)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: SCO packet for unknown connection handle 50346
I get periods of up to a minute of clicks and pops, then it goes away, often for several hours. It's worse when the speaker is futher away from the Pi.
@MilhouseVH many thanks for that! It let me to here which others might find useful.
FYI on libreELEC (Rpi 3+) the fix cures the stuttering but introduces an unacceptable audio delay if the movie is being served over WiFi. I guess it is a limitation of the platform.
Is the audio delay fixed? Can you correct for it using audio delay?
https://kodi.wiki/view/Video_playback#Audio_and_Subtitle_Settings
I moved my data from the builtin wlan0 to eth0 and bluetooth issues were resolved. Unfortunately we cannot have our cake and eat it too :(
I will have to try the NVRAM suggestion above when I get a chance.
I am still experiencing stuttering after trying all kind of fixes on my RPi 3+. Will disable wifi completely and use wire. :(
Well. I'm happy to be another data point. The NVRAM fix totally changed my project-on-a-whim building an A2DP source using my zero-w. I started the project yesterday and until I came upon this thread both pulseaudio and bluez-alsa were completely unusable while wifi was in use. Not having wifi would also be a show-stopper. Thanks much to the people who dug through the chip sources and found the fix.
I still have a small bit of popping and wheezing when the CPU gets overloaded (such as running updates while playing bluetooth) but other than that it's a totally different machine. For the record, I'm running Arch 4.14.90, Bluez 5.50, and Pulseaudio 12.2. Meaning this should work for the foreseeable future and isn't a solution that involves running really old incompatible software. <3
I edited the settings in the NVRAM files:
/usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt
/usr/lib/firmware/updates/brcm/brcmfmac43455-sdio.txt
@acegallagher: I dont understand your comment. Any explanation would be appreciated.
If you have some kind of solution what steps needed to have it on RPI?
@pelwell
The updated NVRAM files have been in Raspbian updates since August 2018. Alternatively you can download them directly:
Copy them into the /lib/firmware/brcm folder (you will need to sudo cp ...
).
Sorry but that doesn't work. Still have stuttering with Wifi.
That's a shame. Did you reboot after installing?
Unfortunately there are limits to what can be achieved with a shared antenna. Have you tried changing the distance from the Pi to the AP and/or the BT device?
Yes, have struggled with this for some months now. I switched to the network cable and no problems any more.
Hi,
With the updated /usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt and friend, and yes I rebooted :-), I still hear underruns on usb audio that are not there with on-board audio (every 5 seconds or so).
Not using wifi, all ethernet.
If on the otherhand I do ifconfig wlan0 down first, then all is fine...!
oh, no, it isn't. just far less
You're reporting stuttering USB audio with Ethernet in an issue about Bluetooth audio with WiFi?
oops!
This Bluetooth + WiFi issue is causing issues with my keyboard doing multiple keystrokes for 1 key down up.
@pratt-jeremy Is that a wireless keyboard?
I have the same problem. Running Arch on a Pi B3, B3+ and Zero. All exhibit the same symptoms: Choppy play with a2dp. Arch has not updated the firmware as listed here, but I did that manually first. If I use the onboard BT on these 3 machines, Bluealsa complains of buffer under runs and it plays music in spurts. The journal shows a buffer under run. If I use a USB dongle it all works as expected. Can we try anything else? fwiw, my kernel is 4.19.32
It seems clear to me that putting bluetooth and wifi on a RPi is like making a silk purse out of a sow's ear.
The Raspberry Pi development team should state that playing audio over bluetooth whilst playing a video over wifi is simply unsupported thanks to a lack of horsepower / bandwidth.
Since day one the Pi has been touted as an updated replacement for the BBC micro, for teaching kids in schools. Kodi was a major bonus. I have just given up on this idea. I wanted to serve films to a pi-top with a bluetooth link to my caravan's audio system, but now I just plug a movie hard drive into a usb port. No Wifi, no stuttering. Sad, but not too inconvenient.
Is this the appropriate command to run to get the onboard BT working?
/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
This is the command in the service file for Arch Linux with the default install of Bluez 5.50
So I have streaming audio to a B3+ with wifi enabled and active (I am logged in via ssh). I am running Arch Linux. I had to install bluez-utils-compat to get the hciattach command installed. I believe Raspian has this already...
cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (352800/8)
period_size: 4410
buffer_size: 22050
The default Bluez 5.50 package has btattach which Arch uses to turn on the BT adapter. This did not work. All I got was stuttering sound. This the Arch pi-bluetooth package calls for the command to be:
ExecStart=/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
The command that worked was from an older version of the package:
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 921600 noflow -
I do not claim to know if this is 'correct' or whatever, just that this is the first time I have had smooth playing bluetooth using the onboard adapter.
Just to avoid confusions. Broadcom WiFi tech was bought by Cypress back in June 2016. Since then
@pratt-jeremy Is that a wireless keyboard?
@JamesH65 yes, it's a bluetooth keyboard I see this was for audio, but thought i'd mention it. Once I turned off the wifi the bluetooth keyboard worked perfectly. No repeated characters i didn't press.
Presumably your distro is fully up to date?
Presumably your distro is fully up to date?
It was up to date when I posted here, it's probably out of date by now since it was in Mar. I'll update and see if it still is happening.
On an RPI4 with WiFi soft blocked in rfkill. Still choppy on Pulseaudio A2DP.
Most helpful comment
I decided to dig into the drivers a little. Reading through the code gave me some insight into some of the module parameters that are supported, and with some experimentation and a shotgun approach, I seem to have gotten bluetooth + wifi working perfectly in conjunction with each other.
I was able to perform a speedtest from the pi over wifi, while my phone played A2DP audio through the pi, and I didn't get a single glitch.
I created a file
/etc/modules.d/bt-wifi-fix.conf
debug=0x00000004
enables info level logging, which isn't really necessary.fcmode=2
appears to enable some kind of hardware flow control, which seemed to make things a little better, but still not great.feature_disable=0x96
is the option that seemed to really fix it. I'm not certain, but I _think_0x96
is trying to disable all optional features, hence why I said 'shotgun approach' above. With some patience it's probably possible to narrow this down to a small subset of features.So far this has worked perfectly for me - I'll report back if I am able to narrow things down further.
EDIT: I get a little bit of glitching when I first start a stream, but absolutely nothing that seems dependent on whether I'm using wifi or not.