• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

moOde audio player for Raspberry Pi

It's dts, and it works fine, I mean it plays. I see dts in the list, so it's supported. I just can't figure out if it is really downmixed to 2 channels automatically.
Try Menu > Audio info to see the final output format delivered to the audio device.

Here's an example

This album below is a 2 disk set containing both a Stereo and 6-channel version.

# Stereo
Screenshot 2025-12-30 at 11.03.01 AM.png
# 6-channel down mixed to Stereo
Screenshot 2025-12-30 at 11.03.25 AM.png
# 6-channel over HDMI to an AVR
Screenshot 2025-12-30 at 7.48.23 AM.png
 
I am experiencing a "click/pop" from my SMSL SU-1 DAC whenever audio starts, pauses, or stops it happens via Spotify Connect and also internet radio playback. I'm guessing this has to be an issue with DAC's relay engaging/disengaging when the XMOS receiver loses the bitstream.

My Setup:
  • Hardware: Raspberry Pi 4B 8GB (Argon One Case)
  • DAC: SMSL SU-1 (XMOS XU-316) connected via USB
  • Audio Config: SoX Resampling enabled (24-bit/44.1kHz)
What I've tried:
  1. Modified mpd.confwith always_on "yes"and close_on_pause "no".
  2. Disabled USB autosuspend in cmdline.txt.
  3. Connected to USB 2 and 3

Any help would be much appreciated.

Thanks for the fantastic work btw.
 
I'm hoping for a similar hack to the one in that reddit post but for Moode on Pi
IIUC that config option is part of the SMSL XMOS UAC2 driver. If someone figures out what that option actually does technically (e.g. by capturing/analyzing the USB communication in wireshark), I am sure linux could do that too (may require some coding, of course).

The option can keep the device open (not switching altsetting to zero) but stop sending samples, keep sending zero-filled samples instead of closing the device, send some custom USB message to the USB device controller, ...
 
It should be keeping the channel open, instead of shutting it down upon stream-end.
I believe MPD has an option meant for that (it probably keeps playing silence, hence fooling the DAC, keeping it playing...)
Cannot remember, but I am sure I heard about it.
 
It should be keeping the channel open, instead of shutting it down upon stream-end.
I believe MPD has an option meant for that (it probably keeps playing silence, hence fooling the DAC, keeping it playing...)
Cannot remember, but I am sure I heard about it.
The option is "close on pause", on the MPD settings page. "Close the ALSA device while playback is paused. This defaults to yes because it allows other applications to use the device while MPD is paused." That's a strange default - what other applications?
 
It should be keeping the channel open, instead of shutting it down upon stream-end.
I believe MPD has an option meant for that (it probably keeps playing silence, hence fooling the DAC, keeping it playing...)
Cannot remember, but I am sure I heard about it.

Maybe you remember this. In the mpd.conf file I set always_on "yes"and close_on_pause "no" but it stopped Spotify Connect from working for some reason.
 
The option is "close on pause", on the MPD settings page. "Close the ALSA device while playback is paused. This defaults to yes because it allows other applications to use the device while MPD is paused." That's a strange default - what other applications?
It's not strange at all - keeping the interface open when paused is only needed with badly behaved audio devices, so in most cases there isn't a down side to closing it being the default. On the other hand the authors don't know what else the end user is going to have running, so freeing the audio device when it's not in use is good practice. Even in an appliance-type use case there could be other sources like squeezelite running. On a desktop it could be anything, although these days a desktop will probably have PipeWire emulating the ALSA interface.
 
The option is "close on pause", on the MPD settings page. "Close the ALSA device while playback is paused. This defaults to yes because it allows other applications to use the device while MPD is paused." That's a strange default - what other applications?

Playback applications include Bluetooth, AirPlay, Spotify Connect, Squeezelite etc. These 3rd party applications need access to the audio device when a client connects. If MPD didn't close the audio output when its not playing these other apps would bomb. Its similar to what @somebodyelse mentioned.

Some users run an MPD-only configuration and can safely leave the "Close on pause" option set to "No" if desired. There is a subtlety to this option though. If MPD is sent a "stop" command instead of "pause" to end playback the audio output is closed. Yes there are two MPD play state commands that can end playback; pause and stop. Stop is used when ending playback of an Internet radio stream.
 
@Tim Curtis,
Any feedback on the "initramfs-tools" error when running update on RPi4 or RPi5 with Moode 10.3 installed?

sudo apt-get update
sudo apt-get upgrade

Processing triggers for initramfs-tools (0.148.3+rpt2) ...
update-initramfs: Generating /boot/initrd.img-6.12.47+rpt-rpi-v8
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /etc/initramfs-tools

Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /boot/initrd.img-6.12.47+rpt-rpi-v8 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.41-12+rpt1) ...
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for debianutils (5.23.2) ...
Errors were encountered while processing:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

If I ignore the error and reboot Moode still works.
I made the mistake of trying to have AI help resolve the issue and that card was unbootable afterwards. :D
Even after creating a fresh install on card with Raspberry Pi Imager the same error occurs if the update is run.

Any ideas?

Thank you!
 
lol, hallucinating AI again

You mean from this thread in our Forum?

I'm not sure whats happening but I'll look into it in the coming days. It might take a while due to the stack of TODO's for upcoming 10.0.4
 
lol, hallucinating AI again

You mean from this thread in our Forum?

I'm not sure whats happening but I'll look into it in the coming days. It might take a while due to the stack of TODO's for upcoming 10.0.4

Tim,
I have not seen that thread before.
Is it best to never run a Raspberry PI OS update on an RPI5 if Moode 10.3 is installed?

Thank you!
 
Prolly not until this issue has been investigated and a possible fix or workaround created. I normally apt upgrade all my systems and I've never had a problem.
 
@Tim Curtis,
Any feedback on the "initramfs-tools" error when running update on RPi4 or RPi5 with Moode 10.3 installed?

sudo apt-get update
sudo apt-get upgrade

Processing triggers for initramfs-tools (0.148.3+rpt2) ...
update-initramfs: Generating /boot/initrd.img-6.12.47+rpt-rpi-v8
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /etc/initramfs-tools

Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /boot/initrd.img-6.12.47+rpt-rpi-v8 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.41-12+rpt1) ...
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for debianutils (5.23.2) ...
Errors were encountered while processing:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

If I ignore the error and reboot Moode still works.
I made the mistake of trying to have AI help resolve the issue and that card was unbootable afterwards. :D
Even after creating a fresh install on card with Raspberry Pi Imager the same error occurs if the update is run.

Any ideas?

Thank you!
I was able to repro.

It looks like only the kernel install fails.

Code:
sudo apt -y install "linux-image-rpi-v8=1:6.12.62-1+rpt1" "linux-image-rpi-2712=1:6.12.62-1+rpt1"
Setting up linux-image-6.12.62+rpt-rpi-2712 (1:6.12.62-1+rpt1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.62+rpt-rpi-2712
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /etc/initramfs-tools
Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for /boot/initrd.img-6.12.62+rpt-rpi-2712 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
.
.
fail
fail

If you apply the patch below, apt upgrade including the kernel should complete successfully. This only applies to a system that has not previously experienced the kernel install fail.
sudo sed -i 's/^MODULES.*/MODULES=most/' /etc/initramfs-tools/initramfs.conf

If you already ran apt upgrade and the kernel install failed then try applying the patch followed by
sudo apt -y --reinstall install "linux-image-rpi-v8=1:6.12.62-1+rpt1" "linux-image-rpi-2712=1:6.12.62-1+rpt1"

Seems super Linux-nerdy but a lot of our users want to keep their systems fully updated outside of our own in-place update feature which only does moode packages and kernel upgrades. We generally support this but sometimes there are challenges :-)
 
If you apply the patch below, apt upgrade including the kernel should complete successfully. This only applies to a system that has not previously experienced the kernel install fail.
sudo sed -i 's/^MODULES.*/MODULES=most/' /etc/initramfs-tools/initramfs.conf

If you already ran apt upgrade and the kernel install failed then try applying the patch followed by
sudo apt -y --reinstall install "linux-image-rpi-v8=1:6.12.62-1+rpt1" "linux-image-rpi-2712=1:6.12.62-1+rpt1"

Seems super Linux-nerdy but a lot of our users want to keep their systems fully updated outside of our own in-place update feature which only does moode packages and kernel upgrades. We generally support this but sometimes there are challenges :-)

Dear Tim,
Thank you for responding. When I ran the two sudo commands above on a RPi4 that had reported the error previously. It reported errors again. I ran the update again after rebooting:

sudo apt-get update
sudo apt-get upgrade

The RPi4 hung and stopped responding to SSH.
The log is below:

Log Summary:
Upgrading: 0, Installing: 0, Reinstalling: 2, Removing: 0, Not Upgrading: 1
9 not fully installed or removed.
Space needed: 0 B / 53.4 GB available

Error: Internal Error, No file name for linux-image-rpi-2712:arm64
Moode3:~ $ sudo apt-get update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://deb.debian.org/debian trixie-updates InRelease [47.3 kB]
Get:3 http://deb.debian.org/debian-security trixie-security InRelease [43.4 kB]
Get:4 http://archive.raspberrypi.com/debian trixie InRelease [54.8 kB]
Get:5 http://deb.debian.org/debian-security trixie-security/main armhf Packages [90.2 kB]
Get:6 http://deb.debian.org/debian-security trixie-security/main arm64 Packages [96.2 kB]
Get:7 http://deb.debian.org/debian-security trixie-security/main Translation-en [60.6 kB]
Get:8 https://dl.cloudsmith.io/public/moodeaudio/m8y/deb/raspbian trixie InRelease [11.7 kB]
Get:9 https://dl.cloudsmith.io/public/moodeaudio/m8y/deb/raspbian trixie/main armhf Packages [5,118 B]
Get:10 http://archive.raspberrypi.com/debian trixie/main armhf Packages [373 kB]
Get:11 https://dl.cloudsmith.io/public/moodeaudio/m8y/deb/raspbian trixie/main arm64 Packages [99.1 kB]
Get:12 http://archive.raspberrypi.com/debian trixie/main arm64 Packages [376 kB]
Fetched 1,258 kB in 2s (745 kB/s)
Reading package lists... Done
Moode3:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
caps moode-player
The following packages will be upgraded:
rpi-connect-lite rpi-eeprom
2 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
9 not fully installed or removed.
Need to get 12.8 MB of archives.
After this operation, 1,181 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://archive.raspberrypi.com/debian trixie/main arm64 rpi-connect-lite arm64 2.7.0 [8,186 kB]
Get:2 http://archive.raspberrypi.com/debian trixie/main arm64 rpi-eeprom all 28.12-1 [4,625 kB]
Fetched 12.8 MB in 3s (4,045 kB/s)
Reading changelogs... Done
(Reading database ... 108530 files and directories currently installed.)
Preparing to unpack .../rpi-connect-lite_2.7.0_arm64.deb ...
Unpacking rpi-connect-lite (2.7.0) over (2.6.1) ...
Preparing to unpack .../rpi-eeprom_28.12-1_all.deb ...
Unpacking rpi-eeprom (28.12-1) over (28.10-1) ...
Setting up initramfs-tools (0.148.3+rpt2) ...
update-initramfs: deferring update (trigger activated)
Setting up rpi-connect-lite (2.7.0) ...

For Raspberry Pi OS Lite, enable user lingering for your user:

loginctl enable-linger

This allows users who are not logged in to run long-running services.

For information on getting started with Raspberry Pi Connect, please see the official documentation:

https://rptl.io/rpi-connect

Setting up rpi-eeprom (28.12-1) ...
Setting up linux-image-6.12.62+rpt-rpi-2712 (1:6.12.62-1+rpt1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.62+rpt-rpi-2712
'/boot/initrd.img-6.12.62+rpt-rpi-2712' -> '/boot/firmware/initramfs_2712'
/etc/kernel/postinst.d/z50-raspi-firmware:
'/boot/vmlinuz-6.12.62+rpt-rpi-2712' -> '/boot/firmware/kernel_2712.img'
Setting up linux-image-6.12.62+rpt-rpi-v8 (1:6.12.62-1+rpt1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.62+rpt-rpi-v8

---- time out -------
Reboot allowed Moode to restart.
 
Hard to say what might be happening on that system.

Doing a quick simulation and no issues finding the kernel packages
Code:
pi@test2:~ $ sudo apt -s --reinstall install "linux-image-rpi-v8=1:6.12.62-1+rpt1" "linux-image-rpi-2712=1:6.12.62-1+rpt1"

Summary:                       
  Upgrading: 0, Installing: 0, Reinstalling: 2, Removing: 0, Not Upgrading: 1
Inst linux-image-rpi-2712 [1:6.12.62-1+rpt1] (1:6.12.62-1+rpt1 Raspberry Pi Foundation:stable [arm64])
Inst linux-image-rpi-v8 [1:6.12.62-1+rpt1] (1:6.12.62-1+rpt1 Raspberry Pi Foundation:stable [arm64])
Conf linux-image-rpi-2712 (1:6.12.62-1+rpt1 Raspberry Pi Foundation:stable [arm64])
Conf linux-image-rpi-v8 (1:6.12.62-1+rpt1 Raspberry Pi Foundation:stable [arm64])
 
IMO reinstalling that machine is the best option now. It seems to be messed up somehow which is difficult to fix remotely via forum interaction. Fixing would likely require direct access (not only remote ssh), keyboard, monitor... IMO not worth the hassle.
 
What is the best 7" screen for an RPi5 running Moode with a stand?
Looking for something that looks nice with the new meters and the RPi5 attaches to the back with as few cables as possible.

Also, does the meter function impact sound quality or CPU usage?

Thanks!
 
Last edited:
Back
Top Bottom