Thank you for your donation!


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


Howdy!
#1
Just another Pi tinkerer here, coming back to Moode Audio after experimenting with various music streaming solutions. I've been running a dedicated music streamer setup on a Raspberry Pi Zero 2 W, cycling through Raspotify, Mopidy, Volumio, and Moode Audio over the past few years.

My current setup is intentionally minimal: just the Pi Zero 2 W connected via Bluetooth to a receiver that feeds into my tuner/amp. I'm somewhere between hobbyist and technical user - comfortable with config files and troubleshooting, but not diving deep into kernel modifications.

The main reason I'm returning to Moode Audio is the frustrating Spotify Connect drops I've been experiencing with raw Raspotify.

My current challenge is maintaining stable Bluetooth connections. The audio quality is great when it works, but I'm getting intermittent drops and reconnection issues that are impacting the listening experience.

Looking forward to contributing and learning from everyone here.
Reply
#2
Welcome to the Forums!
----------------
Robert
Reply
#3
Just a quick wild guess...
Is it not the BT and wireless LAN could interfere with each-other...? I know a Zero doesn't offer much in regard, as alternatives, but I remember having read so somewhere sometime.
Something like BT uses 5.4GHz channels, same as WLAN (but here you can switch to 2.4GHz...)
Reply
#4
(07-14-2025, 02:27 PM)Nutul Wrote: Just a quick wild guess...
Is it not the BT and wireless LAN could interfere with each-other...? I know a Zero doesn't offer much in regard, as alternatives, but I remember having read so somewhere sometime.
Something like BT uses 5.4GHz channels, same as WLAN (but here you can switch to 2.4GHz...)

That is a good guess, but the problem persists even after disabling the wifi.

The logs were reading like a power margent problem to my robot friend. I did not have this problem with bullseye on this device. Right now I'm considering  downgrading to a moode that runs on Bullseye, if there is still such a thing.
Reply
#5
On what PSU are you? Are there "several" USB devices attached? If it looked like a power issue, it might indeed be...
Ooops, you say "power management", that is, the OS automatically puts to sleep a device. There are ways in Linux to prevent this for particular devices; none of which comes to mind now, but some fellows around here might jump in and tell the tale.
Reply
#6
(07-18-2025, 01:23 AM)Eberdeb Wrote:
(07-14-2025, 02:27 PM)Nutul Wrote: Just a quick wild guess...
Is it not the BT and wireless LAN could interfere with each-other...? I know a Zero doesn't offer much in regard, as alternatives, but I remember having read so somewhere sometime.
Something like BT uses 5.4GHz channels, same as WLAN (but here you can switch to 2.4GHz...)

That is a good guess, but the problem persists even after disabling the wifi.

The logs were reading like a power margent problem to my robot friend. I did not have this problem with bullseye on this device. Right now I'm considering  downgrading to a moode that runs on Bullseye, if there is still such a thing.

Don’t make us guess.show us the logs. While we’re at it, what is your power supply?

Regards,
Kent
Reply
#7
(07-18-2025, 06:08 PM)TheOldPresbyope Wrote: Don’t make us guess.show us the logs. While we’re at it, what is your power supply?

Regards,
Kent

Apologies for making you guess for so long - I hadn't intended this to be a help thread as I still had things to try.  Life also got in the way a bit here.

My downgrade to Moode 8 something or other, running on Bullseye did correlate with the Bluetooth issue not being present.

I went back to Moode 9.3.7 to get the logs that were requested and readily reproduced the issue.

Code:
Jul 22 22:05:12 rasp-radio systemd[1]: Stopping mpd.service - Music Player Daemon...
Jul 22 22:05:13 rasp-radio systemd[1]: mpd.service: Deactivated successfully.
Jul 22 22:05:13 rasp-radio systemd[1]: Stopped mpd.service - Music Player Daemon.
Jul 22 22:05:13 rasp-radio systemd[1]: mpd.service: Consumed 5.071s CPU time.
Jul 22 22:05:13 rasp-radio systemd[1]: Starting mpd.service - Music Player Daemon...
Jul 22 22:05:14 rasp-radio mpd[79675]: Ignoring the 'pid_file' setting in systemd mode
Jul 22 22:05:14 rasp-radio systemd[1]: Started mpd.service - Music Player Daemon.
Jul 22 22:05:45 rasp-radio systemd[1]: systemd-timedated.service: Deactivated successfully.
Jul 22 22:05:46 rasp-radio bluetoothd[1597]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 88:C6:26:10:16:B7: Connection refused (111)
Jul 22 22:05:48 rasp-radio kernel: Bluetooth: hci0: command 0x041f tx timeout
Jul 22 22:07:09 rasp-radio dbus-daemon[431]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.680' (uid=0 pid=79943 comm="timedatectl")
Jul 22 22:07:09 rasp-radio systemd[1]: Starting systemd-timedated.service - Time & Date Service...
Jul 22 22:07:10 rasp-radio dbus-daemon[431]: [system] Successfully activated service 'org.freedesktop.timedate1'
Jul 22 22:07:10 rasp-radio systemd[1]: Started systemd-timedated.service - Time & Date Service.
Jul 22 22:07:17 rasp-radio kernel: Bluetooth: hci0: command 0x041f tx timeout
Jul 22 22:07:21 rasp-radio systemd[1]: Stopping mpd.service - Music Player Daemon...
Jul 22 22:07:21 rasp-radio systemd[1]: mpd.service: Deactivated successfully.
Jul 22 22:07:21 rasp-radio systemd[1]: Stopped mpd.service - Music Player Daemon.
Jul 22 22:07:21 rasp-radio systemd[1]: Starting mpd.service - Music Player Daemon...
Jul 22 22:07:22 rasp-radio mpd[80078]: Ignoring the 'pid_file' setting in systemd mode
Jul 22 22:07:22 rasp-radio systemd[1]: Started mpd.service - Music Player Daemon.

One of my Robot Friends had this to say about that (this is the first time one of them had mentioned ertm)
Quote:Power Management Issues (Most Common):
  • Raspberry Pi's USB/Bluetooth power management may be putting the adapter to sleep
  • The Bluetooth device itself might be going into power-save mode
  • Check:
    sudo cat /sys/module/bluetooth/parameters/disable_ertm
  • (should be Y)

When I tried `sudo cat /sys/module/bluetooth/parameters/disable_ertm` it gave me `N`.

The robot friend then had this to say

Quote:Fix this by disabling ERTM:

bash
Code:
# Temporary fix (until reboot)
echo 1 | sudo tee /sys/module/bluetooth/parameters/disable_ertm

# Permanent fix - add to boot configuration
echo 'options bluetooth disable_ertm=1' | sudo tee -a /etc/modprobe.d/bluetooth.conf

# Then restart Bluetooth services
sudo systemctl restart bluetooth
sudo systemctl restart bluealsa

I've tried that and things seem to be working for about 14 hours straight now (which is a new record).  

Given my luck, it will probably break soon after I post this, but here's to hoping.

(Also, in answer to the power supply question, I'm using the "20W usb A" outlet on this https://www.amazon.com/dp/B0B214W8D8?ref...in_title_7)

Thanks for your interest and advice!
Reply
#8
@Eberdeb 

Thanks for the answer. All due respect to your friend but "ERTM" stands for Enhanced Retransmission Mode. I don't know how that relates to putting an interface to sleep. All my players return N when I query the parameter and I haven't noticed problems.
I guess if changing the setting works for you, great, but I sure hate not understanding what's going on under the covers Rolleyes

The RPi Zero 2W is very small and pretty parsimonious with power. Nevertheless, I stopped using that model in favor of the RPi 3A+. More memory A bit faster and I find the WiFi and Bluetooth interfaces to be more reliable. 

Even so, I find I have to use a 5 GHz WiFi connection in order for the (2.4 GHz) Bluetooth connection to work without dropouts caused by mutual interference. Are you doing the same?

Regards,
Kent
Reply


Forum Jump: