piCorePlayer, bt stutters when players synchronized

[gian]

Hello All,

I have a single piCorePlayer that drives two BT speakers.
It worked fairly well, but now they stutter if synchronized.

piCorePlayer v6.1.0 | linux 4.19.122-rt52-pcpAudioCore_v7 | piCore v10.3pCP | Squeezelite v1.9.9-1386-pCP

[gian]

I think that the stuttering comes from trying to keep the players in sync.

Issuing top, I see CPU running at 24% with python3 /usr/local/bin/pcp-btspeaker-daemon.py debug.

Could it be a CPU problem?

[bpa]

I think that the stuttering comes from trying to keep the players in sync.

Issuing top, I see CPU running at 24% with python3 /usr/local/bin/pcp-btspeaker-daemon.py debug.

Could it be a CPU problem?

Pi3 & 4 have 4 cores. If one core is running at 100% then CPU loading overall is 25%.

LMS is single threaded so it runs on a single core but transcoding applications will run on other cores and may in fact be mulithreaded (i.e use more than one core)

You should use a tool which shows individual core loading to see if any core is near 100% loaded and to be sure what process is taking up time.

[gian]

Thanks, bpa:

Mem: 194592K used, 801504K free, 14504K shrd, 5240K buff, 68072K cached
CPU0: 5.1% usr 1.0% sys 0.0% nic 93.7% idle 0.0% io 0.0% irq 0.0% sirq
CPU1: 0.0% usr 0.2% sys 0.0% nic 99.7% idle 0.0% io 0.0% irq 0.0% sirq
CPU2: 24.3% usr 75.6% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 0.0% sirq
CPU3: 4.0% usr 0.2% sys 0.0% nic 95.7% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 1.16 1.05 1.01 3/173 2605
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
2598 1 root R 35992 3.6 2 24.5 python3 /usr/local/bin/pcp-btspeaker-daemon.py debug
12038 2598 root S 26004 2.6 0 1.2 /usr/local/bin/squeezelite -o bt_Spark2 -n Spark2 -m 00 1D DF D7 EC 27 -a 160 4 0 -M SqueezeLiteBT -f /dev/null
24395 2598 root S 26004 2.6 3 1.1 /usr/local/bin/squeezelite -o bt_Spark1 -n Spark1 -m 00 1D DF D1 88 46 -a 160 4 0 -M SqueezeLiteBT -f /dev/null
2387 1 root S 79240 7.9 3 0.7 /usr/local/bin/bluealsa --profile=a2dp-source --profile=a2dp-sink --profile=hsp-ag --profile=hfp-ag --aac-afterburner

This is the situation with both speakers running in sync.

[paul-]

Are you trying to run wifi network too?

[gian]

no, on board wifi and bt are disabled.
BT is on USB

[Paul Webster]

Have you tried the onboard BT just in case it (surprisingly) works better?

[bpa]

Mem: 194592K used, 801504K free, 14504K shrd, 5240K buff, 68072K cached
CPU0: 5.1% usr 1.0% sys 0.0% nic 93.7% idle 0.0% io 0.0% irq 0.0% sirq
CPU1: 0.0% usr 0.2% sys 0.0% nic 99.7% idle 0.0% io 0.0% irq 0.0% sirq
CPU2: 24.3% usr 75.6% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 0.0% sirq
CPU3: 4.0% usr 0.2% sys 0.0% nic 95.7% idle 0.0% io 0.0% irq 0.0% sirq

This shows one core CPU2 has 100% loading but strangely 75% is in "sys"
What process is running on this core ?
if it is bluealsa - then could there be a problem with driver ?

What ever the process is - could it be "polling" - making system calls that just hogging CPU and with kernel locks blocking other processes. If so perhaps a bug - maybe less aggressive polling is needed.

[paul-]

I would bet this is just a buffering issue. Or standard sync problems between different devices. I'll see if I can find the time to test a couple of devices. When I originally set it up, I never tried sync.

[paul-]

Just tested tonight using a RPI3B using the rpi built in BT. Wired network.

I have two different earbuds in right now sync'd (Surprised its not that far out of sync) only a millisecond or so between the two ears, which is fully expected in different capabilities of the two devices.

No stuttering, no processor ever above 35%.

squeezelite, bluealsa are both multi-threaded software. So the different threads are all scheduled on various processors. For example for the two devices playing there are 8 squeezelite threads and 12 or 13 bluealsa threads (only 3 are really using CPU)

I would install htop(extension) then add processor to the column view. That should allow you to sort your view a bit better to see what might be causing problems.

[gian]

Have you tried the onboard BT just in case it (surprisingly) works better?

Probably I had tried, but if I moved to an USB dongle must have been for insufficient range.
The speakers are distant about 8m from the Raspi, one is in a bathroom.

[gian]

In the same room I have another Raspi (Raspbian Buster), connected to my main stereo system with a Hifi Berry DAC, connected with eth0, works also as bridged AP.
I have just fixed a problem where the DAC would kill the wifi, moving the channel from 1 to 3.
I found the solution here:

https://www.hifiberry.com/blog/wlan-driver-bug-in-raspberry-pi-kernel/

As a side effect, it looks like the stuttering has reduced a lot (I would almost say vanished, but I am wary to say it is solved).
Interference between the two?
Maybe I should find a way to turn down just the BT on the AP.

[bpa]

In the same room I have another Raspi (Raspbian Buster), connected to my main stereo system with a Hifi Berry DAC, connected with eth0, works also as bridged AP.
I have just fixed a problem where the DAC would kill the wifi, moving the channel from 1 to 3.
I found the solution here:

https://www.hifiberry.com/blog/wlan-driver-bug-in-raspberry-pi-kernel/

As a side effect, it looks like the stuttering has reduced a lot (I would almost say vanished, but I am wary to say it is solved).
Interference between the two?
Maybe I should find a way to turn down just the BT on the AP.

I still think you should find out what process is taking 100%
As Paul has pointed out - except for LMS - most processes are multithreaded and so should not show this issue.
The fact that 75% is in kernel is very odd.
I don't know pcp and its BT stuff - is LMS still a source - if so what version of LMS.
What is the source of the audio stream you are playing ?
There was an LMS bug recently with some internet radio stream where LMS process would load CPU to 100% (I can't remember the usr/sys split)

[gian]

I still think you should find out what process is taking 100%
As Paul has pointed out - except for LMS - most processes are multithreaded and so should not show this issue.
The fact that 75% is in kernel is very odd.
I don't know pcp and its BT stuff - is LMS still a source - if so what version of LMS.
What is the source of the audio stream you are playing ?
There was an LMS bug recently with some internet radio stream where LMS process would load CPU to 100% (I can't remember the usr/sys split)

I will try to go deeper.

Yes, the source is Logitech Media Server Version: 8.3.0 - 1667251155 @ Fri 04 Nov 2022 09:14:25 AM CET

The two bt speakers wake me up with BBC Radio3 every morning, and are synchronized so I can follow "Bach before 7" from bed to shower.

Thank all of you for your help.

[paul-]

8m is pushing the range of bluetooth.