Setting up Bluetooth Speaker with piCorePlayer v3.5.0 optimized for audio

[Grumpy Bob]

Well, using 4.1.0 and after pairing the headphones, Squeezelite refused to start, so the player never showed up in LMS.

Using 4.0.0 everything worked as per my previous experiences with piCorePlayer - the headphones paired, Squeezelite started, and the player appeared in LMS and music can be played.

Maybe this is an issue with the specific BT headphones I have.

R

I've used this Pi Zero setup with 4.0.0 for a couple of weeks now, works well. Last night I did an in situ update to piCorePlayer 4.1.0, and everything still works as it should. I've no idea why the two attempts to set this up from scratch with 4.1.0 failed.

Robert

[RobbH]

I've had a very similar experience to what Grumpy Bob reported. With piCorePlayer 4.1.0 on a Pi Zero W, bluetooth would connect once, and it would play for some time, on one occasion more than four hours. But at some point, it would fall silent, although LMS continued to show that it was playing. Sometimes the speaker's indicator would show that it had disconnected, sometimes not. Either way, pCP still reported that it was connected. Eventually, LMS would throw an error, apparently while attempting to adjust synchronization on another player, and the system would freeze. (This was usually with eight players synchronized.)

pCP would not reconnect to the speaker. Power cycling the speaker made no difference, but everything would work again after rebooting pCP.

I have now switched to 4.0.0 and so far it's working. It's been 23 hours with no issues.

Unlike Grumpy Bob, I haven't yet worked up the courage to try an in situ update to 4.1.0.

[RobbH]

....Unlike Grumpy Bob, I haven't yet worked up the courage to try an in situ update to 4.1.0.

Following up on my previous report, in case somebody stumbles across this thread, as I did, while looking for a solution.

After months of hesitation, I finally tried an in situ update to pcp 4.1.0, but without success. The earlier problems returned, so I went back to 4.0.0. Even with the earlier version, things weren't perfect. The player would still sometimes fall silent, while LMS still showed it as playing, and the bluetooth speaker still indicated that it was connected. But, unlike the situation with 4.1.0, this never brought the entire synchronized system to a halt. I found that if I set a cron job to reboot the player every night, the problem only occurred about once a week.

That was the situation until the recent release of pcp 5.0.0. With a clean install, the player is now performing nearly perfectly. Uptime is more than 42 hours and there have been no issues yet. Bluetooth latency seems much improved, too.

Any further discussion of the issue should probably move to the appropriate release thread in the Linux forum.

[edwin2006]

Thanks for the update!

[cpd73]

PiZeroW?

Does this work with a PiZeroW and a USB bluetooth dongle? Because I'm really struggling to get this to work. I have pcp 5.0.0 installed (clean install), configured pcp for a bluetooth speaker. I can see the speaker/pcp in LMS, and can play music for about 1 minute. After that the audio gets very jittery, and after a few seconds just stops. If I'm ssh'ed into pcp at the time, then the connection is painstakingly slow. I guess something is hogging the CPU, but top updates so badly its hard to tell. During initial playback, squeezelite is only consuming 5-10% CPU.

Am I doing something wrong? Or does USB bluetooth + inbuilt WiFi on a PiZeroW just not work?

[Greg Erskine]

hi cpd73,

Unfortunately I don't have any blue tooth devices. Hopefully one of the other guys will jump in.

But I was working on something else recently on a 512MB RPi and I just about ran out of RAM. Weird things started happening.

regards
Greg

[paul-]

I test bluetooth on a ZeroW all the time. But I'm using the onboard Bluetooth and wifi. What USB stick are you trying?

The problem stems from Bluetooth are very close to the same frequencies. When you use the onboard Wifi and Bluetooth the chipset does broadcast sharing, meaning it does wifi traffic, and then does bluetooth, alternating back and forth. Since you are using different devices, they don't know they need to live together, what you can try is to put the bluetooth stick on an extension cable to get it away from the ZeroW. Also, make sure you have disabled the onboard bluetooth.

[Grumpy Bob]

Does this work with a PiZeroW and a USB bluetooth dongle? Because I'm really struggling to get this to work. I have pcp 5.0.0 installed (clean install), configured pcp for a bluetooth speaker. I can see the speaker/pcp in LMS, and can play music for about 1 minute. After that the audio gets very jittery, and after a few seconds just stops. If I'm ssh'ed into pcp at the time, then the connection is painstakingly slow. I guess something is hogging the CPU, but top updates so badly its hard to tell. During initial playback, squeezelite is only consuming 5-10% CPU.

Am I doing something wrong? Or does USB bluetooth + inbuilt WiFi on a PiZeroW just not work?

As I write, I'm listening to music via a PiZeroW and a pair of Bowers & Wilkins PX bluetooth headphones and the built-in bluetooth - this is the same PiZero I mentioned earlier in this thread. I did an in situ update to PcP 5.0 a few days ago and it's behaving perfectly. I am connected to the server by WiFi.

I haven't tried a clean install of 5.0.0, but given my experience with the 4.1.0 clean install, I'd be reluctant.

Robert

Edit: I always use the standard PcP, not the experimental real-time kernel version.

[cpd73]

I test bluetooth on a ZeroW all the time. But I'm using the onboard Bluetooth and wifi.

I cannot get this combination to work. Using onboard Bluetooth and wifi; played for about 2 minutes, player went missing from LMS but continued to play for another 30 seconds before stopping. After a further 30 seconds, playback restarted, and player re-appeared in LMS. Whilst music stopped/not in LMS, top did not show high CPU but it also seemed to get stuck displaying only 2 or 3 processes. Played next song to completion, then did not play next. ssh session unresponsive. After a few minutes I could play another track, but ssh again was unresponsive.

What USB stick are you trying?

Just a cheap belkin dongle

The problem stems from Bluetooth are very close to the same frequencies. When you use the onboard Wifi and Bluetooth the chipset does broadcast sharing, meaning it does wifi traffic, and then does bluetooth, alternating back and forth. Since you are using different devices, they don't know they need to live together, what you can try is to put the bluetooth stick on an extension cable to get it away from the ZeroW. Also, make sure you have disabled the onboard bluetooth.

That seems to have done the trick. I've placed the dongle on a 1m extension cable, and its up to its 5th track with no dropouts.

Thanks for your help.

[RobbH]

(Originally Posted by paul-: I test bluetooth on a ZeroW all the time. But I'm using the onboard Bluetooth and wifi.)

I cannot get this combination to work. Using onboard Bluetooth and wifi; played for about 2 minutes, player went missing from LMS but continued to play for another 30 seconds before stopping....

It's interesting that you had problems with this combination on 5.0.0 that are similar (but not quite identical) to the issues I had with the same combination on pcp 4.0.0 and 4.1.0, Bob had issues with 4.1.0, but not 4.0.0, and an in situ update to 4.1.0 worked for him, and it's still working after an in situ update to 5.0.0. In my case, it was a clean install of 5.0.0 that made this combination work.

Obviously, that are a lot of variables at play here, and many of them are not under the control of the pcp team. Manufacturing tolerances on the Zero W, perhaps?

[paul-]

I would guess that channel selection/distance to WAP/enclosure/other wifi traffic has more to do with it.

[RobbH]

I would guess that channel selection/distance to WAP/enclosure/other wifi traffic has more to do with it.

That makes sense, and is bound to be better than my uneducated guess. Just FWIW, my setup -- the one that's working with 5.0.0, but had issues with 4.0.0 and 4.1.0 -- uses channel 6 to connect to an access point about ten feet (approx. 3 meters) away, with a wall between. Distance to the speaker is about 4 feet, slightly more than 1 meter. Two other players, both using the Airplay bridge) are connected to the access point, but nothing else.

The Zero W is in the "official case": https://www.amazon.com/dp/B06XD18H6K..._w7sbDb0JHA009

The access point is a "mini travel router": https://www.amazon.com/dp/B01K6MHRJI..._xetbDbH5HQY7T

[cpd73]

Speaker does not reconnect?

Whilst I've managed to get the speaker to connect and play, it does not always seem to reconnect when connection is lost. If i power off the speaker, LMS still seems to think something is playing - shouldn't the squeezelite instance be stopped? When I power the speaker back on it does not always reconnect - there is no connection beep, and no music is played. Is this a known issue? Or something strange with my setup?

What I'd ideally like is to leave my PiZeroW always switched on, and just turn the bluetooth speaker on when required. Then the music should continue from where it switched off. Is this possible with pCP? I have a python script that I tested on my main (non-pCP) Pi (where LMS is located) that will start squeezelite when a speaker is connected, and stop it when it disconnects - but this requires python and dbus (which I don't think are on pCP?). However, I can't use this as my main Pi is too far away from where I wish to use the bluetooth speaker. So, I was hoping that pCP could do something similar.

[paul-]

What I'd ideally like is to leave my PiZeroW always switched on, and just turn the bluetooth speaker on when required.

I’ve not had luck doing this, as it normally causes BT to not allow new connections

Then the music should continue from where it switched off. Is this possible with pCP? I have a python script that I tested on my main (non-pCP) Pi (where LMS is located) that will start squeezelite when a speaker is connected, and stop it when it disconnects - but this requires python and dbus (which I don't think are on pCP?). However, I can't use this as my main Pi is too far away from where I wish to use the bluetooth speaker. So, I was hoping that pCP could do something similar.

Not using python, but am using dbus and scripts, but generally this is how it works. When squeezelite is disconnected for a while, LMS will not automatically restart either.

[cpd73]

I’ve not had luck doing this, as it normally causes BT to not allow new connections

Ah, OK. Guess I'll try installing plain Raspbian on the Pi, and use my script.