Bluetooth Audio Crackles

[UF_DoC]

Good Day,

I have a Pi Zero W and a Pi 3 that I'm using to play audio through a Bluetooth speaker (JBL Go).

I'm experiencing the same issue on both Pi's where the audio starts off crackly/spluttery for the first 5-10seconds.

I have pulse-audio setup with the pulseaudio-module-bluetooth.

I am trying to play a local mp3 file as follows:
cvlc test.mp3
mplayer test.mp3

Does anyone know what could be causing the crackling and spluttering?

Thanks

[Douglas6]

Are the Pis also using the on-board WiFi? You might want to try using a Bluetooth or WiFi USB dongle.

[UF_DoC]

Yes both WiFi and Bluetooth are in use and required. I would like to avoid using another USB device and understand what the issue is. I assume u are eluding to interference but then what would explain it remaining clear after the first 5 seconds?

[UF_DoC]

Can anyone advise how to debug this issue?

Is it possible to log bluetooth coms hopefully to show some error?

[UF_DoC]

Based on Douglas6 advise, I conducted a test and switched the wifi off:

Code: Select all

sudo ifconfig wlan0 down

I then played the audio file over bluetooth... and 100% clear!
I stopped and started the file a few more times and always 100% clear!

I then enabled the wifi:

Code: Select all

sudo ifconfig wlan0 up

and played the audio file which immediately started crackling again at the beginning (5-10seconds).

RPF, surely this is worth some investigation?

[UF_DoC]

Its a really strange issue, in that, Im not convinced its radio interference.

I played some audio and after the 5-10 second cracklyness it is clear. I even tried downloading a large file in another terminal to "increase" wifi usage. Even with the increased wifi throughput the sound remained clear.

Another observation is that once the sound stabilizes and is clear, if I immediately stop and start the audio playing it starts again clear.

Even stranger... if I stop the clear audio and restart the audio after a time greater than 5seconds it will always start playing crackly again.

I'm beginning to think this is more likely a Bluetooth issue... there is something that happens when you just establish a datalink between the pi and a device. Something that switches off after +-5seconds of inactivity. Maybe we may need a way to keep this link open and not suspend it as a workaround.

[Douglas6]

My guess (and I emphasize 'guess') is buffering. After a few seconds, the stream is sufficiently buffered to allow smooth playback.

There was a post here some weeks ago from an RPF engineer, indicating that Cypress is looking into Bluetooth+WiFi issues. But it' s been an issue for over a year; I'm not holding my breath. Get a USB dongle.

[UF_DoC]

Does not have symptoms of buffering. i.e. When I play a file for more than 10 seconds and it stops crackling, if I stop the playing and start another file within 5 seconds the new file plays crystal clear from the get go.

Another observation/test was I got hold of a "redbear iot phats" https://redbear.cc/product/iot-phat.html which is based on the same chip as the pi3 and zero w.
When testing this with a plain pi zero it exhibited the exact same behavior.

I am convinced it is a chip issue and the guys at cypress should advise.

[UF_DoC]

Hi, is there no one from RPF that​ can confirm/deny this issue and provide details on any fixes being investigated?

[Douglas6]

This is all I've ever heard: viewtopic.php?p=1104854#p1104854

[armyturtle]

I registered an account JUST to come on this post and tell you what the problem was for me. I tried EVERY solution on the web. I tried switching to HDMI audio and using an external device (hardware) I own that pulls the audio off the HDMI and gives me a 3.5 audio jack. I STILL HAD CRACKLES!!!

A couple of times while I was trying some of the solutions I was listening to the audio all cracked up and static-y and it suddenly went clear. It drove me nuts. I couldn't figure out what random shit was going on that suddenly cleared it up.

Finally through some stupid luck I found the problem, and confirmed it several times over.
I think it's a buffer issue.

1. FIRST BEFORE CONNECTING over bluetooth with your other device (for me I was using my Android phone), START PLAYING SOME MUSIC.
2. WHILE the music is already playing on your phone (or other device), NOW CONNECT to your raspberry pi via bluetooth. The audio on your phone will likely pause immediately - that's okay.
3. Now that you're actively connected to your pi via bluetooth, start playing the music again - this time it will be crystal clear.

Without this specific order of playing music, the audio would be not only static-y and crackly, but slowed down as well (dragged out). It's for this reason I believe this to be some type of a buffer and/or memory issue. If you just connect bluetooth first between your phone (or other device) and the pi, then suddenly start throwing audio at it, it results in snap, crackle, pop, and slowmo audio.

To confirm, I rebooted the pi several times and played audio in the same order:
1. play audio on phone first
2. while audio is playing on my phone, go into bluetooth settings and tell the phone to connect to the pi.
3. audio will have stopped, but now that your bluetooth is connected to the pi, go back and play the audio again.

When trying to just connect bluetooth first, then play audio, it consistently reproduced the snap, crackle, & pop crap.

Really hope this helps someone. Also, if anyone knows how to dedicate more memory/cpu cycles to the audio part of the pi, I bet this might fix this stupid order of operations to get it to connect.

Let me know if you have success like I did!