Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Problem: Bluetooth audio lag due to cpu overload
#11
Also the cpu overload and audio scratch / lag getting worse in the following case:
Stream a music to rpi zero w via bluetooth
Let music end and wait at least one minute
Stream a new music.

In this case audio stream is now inaudible (scratch/lag every 1 or 2 sec).
Even worse, after a while the system crash (hard reboot is necessary).


Is some particular logs could help you?
Reply
#12
Is your power supply adequate? I had a lot of issues with a zero before switching to a beefier PSU
Reply
#13
Yes, i'm using the same power supply as for my rpi 3B+ (running recalbox without any power issue)
Reply
#14
@Norde

I'm trying to recreate your same situation here. Have an RPi0W running moOde 6.1.0 and driving a Khadas Tone Board DAC via USB. The moOdeOs is on a 16GB SanDisk Ultra uSD card. Powered via the RPi's microUSB port by a Canakit 2.5a RPi power supply. Running RadioDroid app on my Nexus 6P phone, streaming Radio Paradise to the RPi0W via BT.

So far, I have not experienced the symptoms you describe. There's a bit of a lag (<1s) from when I punch "play" on the phone to getting sound out of moOde (but see below). Nothing like your description of "scratchy."

I see in your limited htop output that you have the SSH Term Server (shellinaboxd) and the UPnP client (upmpdcli) enabled so I have too. What else have you done to customize your system?

So, just to be thorough, I plugged the Khadas Tone Board into an RPi4B powered via the RPi's USB-C port by an official Raspberry powerpack. Again, moOde 6.1.0 on a 16GB SanDisk Ultra uSD card.

I have the same bit of lag so I have to blame it on buffers, on the phone apps, etc., but not on the RPi0w. 

No inaudibility issues and no system crash on either RPi.

Something just came to mind. What is your Bluetooth streaming source and what other Bluetooth or 2.4GHz sources are nearby? In the past I've experienced on-off-on pulsations when there was mutual interference between BT radios. Fer instance, my microwave oven interferes with my phone to BT-earphone connection when I'm in a phone conversation.

Regards,
Kent
Reply
#15
@TheOldPresbyope 

Thanks for your detailled feedback


The only others modified parameters are:
The wifi (ssid, password and country), the MDP configuration (device-type set to USB audio device) and the bluetooth (enabled with pairing agent).

Changing the buffer for bluetooth has no effect on my problem and The same thing happens without SSH Term Server and UPnP client.



Also i do not have any unwanted signal nearby (Bluetooth or 2.4 GHz).
This is confirmed by the use in the same place of a bluetooth gamepad on a rpi 3B + and a bluetooth speaker (UE roll 2) which both perfectly work.



Very strange bug / problem.
I will give a test with my rpi3B + and look for other sources of stream (smartphones or other) to determine if this problem come from my rpi setup or from elsewhere.



Thank you again for all these returns and the time spent looking for where the problem comes from,
Norde
Reply
#16
I did some tests:

My current stream sources are (those with whom I encounter the problem):
- Android Phone Moto G5
- Laptop windows 10

- With the same moOde setup on a rpi 3B +: all fine



I also tried different sources of stream with the rpi zero w as receiver (Android Moto G4, Iphone 6 and desktop PC under windows 10):

- Android Moto G4 with aptX enabled (HD audio): all fine
- Android Moto G4 with aptX off (HD audio): all fine
- Iphone 6: all fine
- Destkop PC windows 10: all fine


Seems that the problem is transmitter depentent. So i redid tests with the Android Moto G5 phone and the windows 10 laptop but this time by placing the moOde governor cpu on "perfomance":
- Android Moto G5 with aptX enabled (HD audio): rare lag / scratch (every 20sec to 2min)
- Android Moto G5 with aptX off (HD audio): lag / scratch rare (every 20sec to 2min)
- Laptop windows 10: all fine

This is a dirty fix but it makes the system viable for use.



I do not know why but the problem depend on the source stream.
Do you have any idea of what might be problematic?
Would it be a problem at Bluez level?
Reply
#17
I don't know the answer. Bluetooth technology is a bit of a mess and I reached my limit of understanding just getting various devices to pair/connect/negotiate the correct protocol.

It certainly wouldn't surprise me to learn that disabling the CPU-frequency generator helps the RPi0w keep up.

As an aside, I don't believe the bluezalsa package used in moOde is compiled to include the aptx codec (there's a question of right-to-use). Even if aptX is enabled on the phone I believe the negotiation which occurs during the connect process will settle on the lower-performing SBC (subband coding) codec as the common denominator between the phone and the BT subsystem in moOde. You'd have to go to the command line and do some low-level "sniffing" to find out.

Regards,
Kent
Reply


Forum Jump: