Pi3 bluetooth audio stutters with Wifi enabled
SebastiaanAdamo opened this issue · 144 comments
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 (OKAY FINE, I'll connect via hdmi instead of vncserver I GUESS ) but I too am waiting on a fix because it seriously limits my ability to make my projects mobile. VNCserver is a must.
+1 that gave me headaches finding this problem out !
I needed WiFi so I just:
- Use a USB dongle as WiFi adapter
- 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.
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.
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
@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 : lukasjapan/bt-speaker#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.
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.
No - that will be the latest (1.2-3+rpt1).
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.
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+?
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!
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.
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:
-
Install the dependencies.
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>
- Reboot Raspberry Pi
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 -
Reboot.
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.