• 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

Tim Curtis said:
Zip up a 5 ch and a mono file and then PM me a download link. I'll see if I can reproduce the issue on my end. One of my systems is a Pi-5 HDMI connected to a 5.1 channel Yammy AVR.

There are some channel options with MPD + SoX and ALSA can perform channel remapping.
Click to expand...
That's very kind of you. I have sent you a direct message.
 
I was able to reproduce the 5 channel file "fails to play" over HDMI. It could very well be a format not supported by the IEC958 standard but I haven't checked the specification out.

I set MPD/SoX to force Stereo and the file played (in stereo) but only for about 20 seconds even though it its Duration tag showed 5 min 39 secs. Very odd.

Your best bet might be to use something like the ffmpeg tool to manually convert the mono files to 2ch mono and the 5ch files to 5.1ch.

According to mediainfo the channel layout is L R C Ls Rs. There is no LFE channel.
Code: 
pi@hsu:~ $ mediainfo "/media//VFAT64/Test/Sashoir/five_channel_segment000.flac"
General
Complete name                            : /media//VFAT64/Test/Sashoir/five_channel_segment000.flac
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
File size                                : 20.3 MiB
Duration                                 : 5 min 39 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 503 kb/s
Album                                    : Pohádka léta (A Summer's Tale), Op. 29
Track name                               : III. Blind Musicians (Slepi hudci)
Track name/Position                      : 3
Performer                                : BBC Symphony Orchestra
Composer                                 : Josef Suk / Josef Suk
Conductor                                : Jiří Bělohlávek
Genre                                    : Classical
Recorded date                            : 2012
Writing application                      : Lavf62.3.100
Cover                                    : Yes
Cover type                               : Cover (front)
Cover MIME                               : image/jpeg
musicbrainz_performer_id                 : 5b13c665-88eb-4e80-9a06-218a660fcf6b
musicbrainz_conductor_id                 : e46933fa-7d2d-467c-b7a0-1d499bc62d51
musicbrainz_composer_id                  : 5b3357b8-c903-4d17-98a8-e19e2824845a
work                                     : Pohádka léta (A Summer's Tale), Op. 29
musicbrainz_work_id                      : 080dd10d-d6d4-4294-9b4f-68c2a4db6bca
subgenre                                 : Orchestral
Album/Composer                           : Suk, Josef

Audio
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
Duration                                 : 5 min 39 s
Bit rate mode                            : Variable
Bit rate                                 : 478 kb/s
Channel(s)                               : 5 channels
Channel layout                           : L R C Ls Rs
Sampling rate                            : 96.0 kHz
Bit depth                                : 24 bits
Compression mode                         : Lossless
Stream size                              : 19.3 MiB (95%)
Writing library                          : Lavf62.3.100
MD5 of the unencoded content             : 0A8B2E23BEBD2EA70384CBD6778F7CD4

Image
Format                                   : JPEG
Muxing mode                              : FLAC Picture
Width                                    : 1 417 pixels
Height                                   : 1 417 pixels
Color space                              : YUV
Chroma subsampling                       : 4:4:4
Bit depth                                : 8 bits
Compression mode                         : Lossy
Stream size                              : 1 014 KiB (5%)
pi@hsu:~ $
 
Tim Curtis said:
I was able to reproduce the 5 channel file "fails to play" over HDMI. It could very well be a format not supported by the IEC958 standard but I haven't checked the specification out.

I set MPD/SoX to force Stereo and the file played (in stereo) but only for about 20 seconds even though it its Duration tag showed 5 min 39 secs. Very odd.

Your best bet might be to use something like the ffmpeg tool to manually convert the mono files to 2ch mono and the 5ch files to 5.1ch.

According to mediainfo the channel layout is L R C Ls Rs. There is no LFE channel.
Code: 
pi@hsu:~ $ mediainfo "/media//VFAT64/Test/Sashoir/five_channel_segment000.flac"
General
Complete name                            : /media//VFAT64/Test/Sashoir/five_channel_segment000.flac
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
File size                                : 20.3 MiB
Duration                                 : 5 min 39 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 503 kb/s
Album                                    : Pohádka léta (A Summer's Tale), Op. 29
Track name                               : III. Blind Musicians (Slepi hudci)
Track name/Position                      : 3
Performer                                : BBC Symphony Orchestra
Composer                                 : Josef Suk / Josef Suk
Conductor                                : Jiří Bělohlávek
Genre                                    : Classical
Recorded date                            : 2012
Writing application                      : Lavf62.3.100
Cover                                    : Yes
Cover type                               : Cover (front)
Cover MIME                               : image/jpeg
musicbrainz_performer_id                 : 5b13c665-88eb-4e80-9a06-218a660fcf6b
musicbrainz_conductor_id                 : e46933fa-7d2d-467c-b7a0-1d499bc62d51
musicbrainz_composer_id                  : 5b3357b8-c903-4d17-98a8-e19e2824845a
work                                     : Pohádka léta (A Summer's Tale), Op. 29
musicbrainz_work_id                      : 080dd10d-d6d4-4294-9b4f-68c2a4db6bca
subgenre                                 : Orchestral
Album/Composer                           : Suk, Josef

Audio
Format                                   : FLAC
Format/Info                              : Free Lossless Audio Codec
Duration                                 : 5 min 39 s
Bit rate mode                            : Variable
Bit rate                                 : 478 kb/s
Channel(s)                               : 5 channels
Channel layout                           : L R C Ls Rs
Sampling rate                            : 96.0 kHz
Bit depth                                : 24 bits
Compression mode                         : Lossless
Stream size                              : 19.3 MiB (95%)
Writing library                          : Lavf62.3.100
MD5 of the unencoded content             : 0A8B2E23BEBD2EA70384CBD6778F7CD4

Image
Format                                   : JPEG
Muxing mode                              : FLAC Picture
Width                                    : 1 417 pixels
Height                                   : 1 417 pixels
Color space                              : YUV
Chroma subsampling                       : 4:4:4
Bit depth                                : 8 bits
Compression mode                         : Lossy
Stream size                              : 1 014 KiB (5%)
pi@hsu:~ $
Click to expand...
Thank you so much for checking. The metadata/actual duration mismatch is because I cropped the file with ffmpeg (because the full track is hundreds of Mbytes). I'm sorry I ought to have told you that!
I agree that padding the source files manually is the simplest solution: I was hoping to avoid it only because I'd like to use CamillaDSP and padding the entire <6 channel library to 6 channels to make them uniform would take rather a long rime (it's about 2Tbytes of files). I may try to get padding with ALSA working in another distribution and, if I succeed, perhaps I can share it here for your reference?
 
Moode uses MPD's .m3u playlist format plus two custom EXT tags at the beginning.

Here is an example. The USB drive is named "VFAT64".
Code: 
pi@test2:~ $ cat /var/lib/mpd/playlists/Test\ Playlist.m3u
#EXTGENRE:Rock
#EXTIMG:default
USB/VFAT64/Test/gap-less_test_tracks/11 To Be Free.flac
USB/VFAT64/Test/gap-less_test_tracks/12 Now More Than Ever.flac
USB/VFAT64/Test/gap-less_test_tracks/15 Prelude.flac
USB/VFAT64/Test/gap-less_test_tracks/16 A.M. Mourning.flac
USB/VFAT64/Test/gap-less_test_tracks/17 P.M. Mourning.flac
USB/VFAT64/Test/gap-less_test_tracks/18 Memories Of Love.flac
pi@test2:~ $
 
This type of external playlist also works. The song files and playlist m3u are on the same USB drive.

Code: 
pi@test2:~ $ ls -1 /media/VFAT64/
Playlists
Test
pi@test2:~ $

pi@test2:~ $ cat /media/VFAT64/Playlists/test_playlist.m3u
#EXTM3U
#EXTINF:239,Nine Inch Nails - Letting You
../Test/Nine Inch Nails/The Slip/03 Letting You.flac
#EXTINF:391,Nine Inch Nails - Discipline
../Test/Nine Inch Nails/The Slip/04 Discipline.flac
pi@test2:~ $

Screenshot 2026-05-04 at 12.29.38 PM.png
 
Sashoir said:
Thank you so much for checking. The metadata/actual duration mismatch is because I cropped the file with ffmpeg (because the full track is hundreds of Mbytes). I'm sorry I ought to have told you that!
I agree that padding the source files manually is the simplest solution: I was hoping to avoid it only because I'd like to use CamillaDSP and padding the entire <6 channel library to 6 channels to make them uniform would take rather a long rime (it's about 2Tbytes of files). I may try to get padding with ALSA working in another distribution and, if I succeed, perhaps I can share it here for your reference?
Click to expand...
For all those interested, I have managed to make the bulk of my source material (mono, stereo, 5.0, and 5.1) work in RPIOS via MPD with CamillaDSP and ALSA. When I have time, I am going to try to replicate the solution in Moode (because it is a lovely bit of software), and will post here if I can manage it.
The first thing I had to do (after installing MPD, CamillaDSP & cetera) was create an ALSA configuration to override the "default" output:
#Loopback is our final destination for audio output
pcm_slave.six_channel_loopback {
pcm "hw:Loopback,0,0"
channels 6
rate 96000
format "S32_LE"
}
#Define a plug for sample rate and format conversion
pcm.conversion_plug {
type plug
slave six_channel_loopback
}
#Define a channel router
pcm.channel_route {
type route
slave.pcm "conversion_plug"
slave.channels 6
ttable {
0.0 1 #ALSA 0=FL -> FLAC 0=FL
1.1 1 #ALSA 1=FR -> FLAC 1=FR
2.4 1 #ALSA 2=RL -> FLAC 4=RL
3.5 1 #ALSA 3=RR -> FLAC 5=RR
4.2 1 #ALSA 4=C -> FLAC 2=C
5.3 1 #ALSA 5=LFE -> FLAC 3=LFE
}
}
#Force our default output to use our router+converter into the loopback
pcm.!default {
type copy
slave.pcm "channel_route"
}

ctl.!default {
type hw
card "Loopback"
}

Then I removed the audio output from my mpd configuration (so it used the default output). For whatever reason, I could *not* get it to work with an audio_output defined in MPD - or rather, it worked, but sent a mono mix of all source channels to each MPD output/Loopback input channel.
In my CDSP configuration, I defined Loopback 1 as my capture device, and vc4hdmi0 as my output devce.
Then I defined the following mixer in CDSP:
1778156171478.png

As you can see, the channels are re-routed again, but the re-routing is not merely inverting/reversing the ALSA routing. When I tried to consolidate the two mappings into the ALSA routing, it didn't work (more than likely I was making an error, but I'd spent long enough on getting *something* working I didn't want to spend any more time fixing it "properly").

As I mentioned, my horrible kludge works with monophonic, stereophonic, 5 and 6 channel flac files. It does *not* work when playing the wav files in /usr/share/sounds/alsa - everything comes out of the (front) Left speaker. It also does *not* work with one quad album that I have, but it does work with the pseudo-quad albums I have which had a silent centre channel.

Although I'd much prefer to use Moode, and my solution is clearly of the "two wrongs making a right" variety, at least I finally have a solution which plays 99% of my music gaplessly and correctly without having to alter my source files, so I'm pleased. Hopefully someone else might benefit. I shall post again here if I can get it working in Moode as well (my php is non-existent, so I have doubts).
 
Is it possible to play (and rip CDs) via Moode?
Also when I boot up Moode, I am able to ssh to it quickly but the web UI takes about 5+ minutes to be available. Is this normal? If not, how to fix it?
 
tc2007 said:
Is it possible to play (and rip CDs) via Moode?
Also when I boot up Moode, I am able to ssh to it quickly but the web UI takes about 5+ minutes to be available. Is this normal? If not, how to fix it?
Click to expand...

Not possible. Best to use one of the very mature and excellent CD ripping utilities to create lossless flac files that can be played in moode.

The symptom "...the web UI takes about 5+ minutes to be available" is highly abnormal and suggests something external to moode software for example network issues, client/browser issues, hardware issues etc.

Since you can SSH in try posting the startup log and I'll have a look.
moodeutl -l
 
Thanks @Tim Curtis for your involvement here.

I am running into a strange issue with clicks and pops playing hires FLACs through the Raspberry Pi's USB-C port. My setup is the following: moOde 10.2.2 on a Raspberry Pi 5 2GB playing a 24 / 192 local FLAC file to my Schiit Modi Plus DAC.

Working configuration: When I (1) connect the Pi to the DAC through the Pi's USB Type A port, (2) power the Pi through its USB-C port, (3) power the DAC through it's on USB-C power, the file plays fine.

Non-working configuration: When I (1) connect the Pi to the DAC through the Pi's USB-C port (having enabled OTG / host mode in config.txt with dtoverlay=dwc2,dr_mode=host under [all], no other config changes) (2) power the Pi through the same USB-C using a Belkin PD/data splitter, it plays the song with randomly timed and large amounts of clicks and pops. In /var/log/mpd/log I see alsa_output: Decoder is too slow; playing silence to avoid xrun periodically appear.

To isolate the issue, I was able to replicate the clicks and pops with the ffmpeg playback command below:

ffmpeg -hide_banner -loglevel warning -i "/home/pi/Daft Punk - Random Access Memories - 01 - Give Life Back to Music.flac" -f s24le - | aplay -D hw:Modi -f S24_3LE -c 2 -r 192000

Possible fix: Changing the container size to 32 bit seems to fix it. Below is the working ffmpeg command:

ffmpeg -hide_banner -loglevel warning -i "/home/pi/Daft Punk - Random Access Memories - 01 - Give Life Back to Music.flac" -f s32le - | aplay -D hw:Modi -f S32_LE -c 2 -r 192000

Based on this, I added format "*:32:*" in the audio_output block of /etc/mpd.conf and that seems to fix the clicks and pops over USB-C for hires files. I am still testing.

Not sure why exactly having a 32-bit container makes the USB-C audio output work.

Edit: The reason I am doing this is to replicate my previous iPad setup, where I had a single USB-C cable plugged into the iPad, split into power + data by the Belkin splitter, and the data end into the USB-C input of the Schiit DAC (which drew its own 5V ~800mA power). This reduced the number of cables and the need for electrical sockets.
 
I wonder if it's the old issue #2215 again? The root cause was never found, but it was specific to the OTG port and it was sensitive to what exactly was running in some counterintuitive ways.
 
somebodyelse said:
I wonder if it's the old issue #2215 again? The root cause was never found, but it was specific to the OTG port and it was sensitive to what exactly was running in some counterintuitive ways.
Click to expand...

This is very related. I don't understand why my fix fixed it. Will debug more today. The USB 3 ports definitely work though, this is all about the USB C otg/dwc2.

Interestingly, this HifiBerryOS page says:
S24_3LE: This format avoids padding altogether but is less compatible with many tools and systems. It’s generally not recommended due to potential compatibility issues.
Click to expand...

So I guess it's not unheard of.
 
Last edited:
entsnack said:
This is very related. I don't understand why my fix fixed it. Will debug more today. The USB 3 ports definitely work though, this is all about the USB C otg/dwc2.

Interestingly, this HifiBerryOS page says:


So I guess it's not unheard of.
Click to expand...

I always thought the RPi5 USB C port was for power adapter only. I never would have plugged it into my DAC when the USB A port was designed for that purpose.
 
amper42 said:
I always thought the RPi5 USB C port was for power adapter only. I never would have plugged it into my DAC when the USB A port was designed for that purpose.
Click to expand...

This changed since the Pi 4B. You just need to add dtoverlay=dwc2,dr_mode=host to your config.txt to have the USB-C port perform dual duty as a power sink and data out. So you can have a nice setup like Pi 5 USB-C <- Belkin USB-C splitter -> USB-C DAC and a single power input to the Belkin for both the Pi 5 and the DAC (I just use a 15W adapter because my DAC consumes 5V, <1A and make sure that my Pi isn't on sustained full load). The other available dr_mode options are peripheral and otg.
 
While the USB-C setup might pass power and data, the crackling is a known consequence of the dwc2 driver. Forcing the USB-C port into Host mode forces the Pi to use the dwc2 driver rather than its standard, highly optimized xHCI controller. The dwc2 driver wasn't designed for heavy, real-time, low-latency USB Audio streaming, which easily leads to dropped packets, buffer underruns, and audible crackles.

Recommended solution: Using the standard RPi5 USB-A port for the Moode DAC connection completely avoids this issue because it routes the signal through the Raspberry Pi 5’s dedicated RP1 southbridge and uses the robust xhci_hcd driver.
 
amper42 said:
While the USB-C setup might pass power and data, the crackling is a known consequence of the dwc2 driver. Forcing the USB-C port into Host mode forces the Pi to use the dwc2 driver rather than its standard, highly optimized xHCI controller. The dwc2 driver wasn't designed for heavy, real-time, low-latency USB Audio streaming, which easily leads to dropped packets, buffer underruns, and audible crackles.

Recommended solution: Using the standard RPi5 USB-A port for the Moode DAC connection completely avoids this issue because it routes the signal through the Raspberry Pi 5’s dedicated RP1 southbridge and uses the robust xhci_hcd driver.
Click to expand...

Or you could do the not-recommended thing that I did if your situation requires it. :-)

That fact that I no longer have crackling negates your "known consequence" claim and treats ASR folks like they do not know how to manage engineering constraints. So you need to back up or qualify your claim instead of hiding behind "standard, highly optimized" (is dwc2 nonstandard? how much worse-optimized is it?) and "heavy, low-latency USB audio streaming" (12 Mbps is heavy and low-latency now?).

There are conditions under which dwc2 leads to the issues you mentioned, and an engineer can balance those constraints with their needs provided enough information.

But the internet is littered with "not recommended" and "not designed for" without additional information.

Next you'll tell me the iPod was not designed for flash storage and not recommended for use with non-Apple firmware ;-)
 
entsnack said:
Thanks @Tim Curtis for your involvement here.

I am running into a strange issue with clicks and pops playing hires FLACs through the Raspberry Pi's USB-C port. My setup is the following: moOde 10.2.2 on a Raspberry Pi 5 2GB playing a 24 / 192 local FLAC file to my Schiit Modi Plus DAC.

Working configuration: When I (1) connect the Pi to the DAC through the Pi's USB Type A port, (2) power the Pi through its USB-C port, (3) power the DAC through it's on USB-C power, the file plays fine.

Non-working configuration: When I (1) connect the Pi to the DAC through the Pi's USB-C port (having enabled OTG / host mode in config.txt with dtoverlay=dwc2,dr_mode=host under [all], no other config changes) (2) power the Pi through the same USB-C using a Belkin PD/data splitter, it plays the song with randomly timed and large amounts of clicks and pops. In /var/log/mpd/log I see alsa_output: Decoder is too slow; playing silence to avoid xrun periodically appear.

To isolate the issue, I was able to replicate the clicks and pops with the ffmpeg playback command below:

ffmpeg -hide_banner -loglevel warning -i "/home/pi/Daft Punk - Random Access Memories - 01 - Give Life Back to Music.flac" -f s24le - | aplay -D hw:Modi -f S24_3LE -c 2 -r 192000

Possible fix: Changing the container size to 32 bit seems to fix it. Below is the working ffmpeg command:

ffmpeg -hide_banner -loglevel warning -i "/home/pi/Daft Punk - Random Access Memories - 01 - Give Life Back to Music.flac" -f s32le - | aplay -D hw:Modi -f S32_LE -c 2 -r 192000

Based on this, I added format "*:32:*" in the audio_output block of /etc/mpd.conf and that seems to fix the clicks and pops over USB-C for hires files. I am still testing.

Not sure why exactly having a 32-bit container makes the USB-C audio output work.

Edit: The reason I am doing this is to replicate my previous iPad setup, where I had a single USB-C cable plugged into the iPad, split into power + data by the Belkin splitter, and the data end into the USB-C input of the Schiit DAC (which drew its own 5V ~800mA power). This reduced the number of cables and the need for electrical sockets.
Click to expand...

Interesting config.

I haven't played around with OTG host mode but maybe I'll find some spare cycles.

If setting MPD to 32 bit format works to eliminate the audio glitches then FYI you can set this in the MPD Config Screen and avoid having to manually edit mpd.conf.

Screenshot 2026-06-05 at 7.50.50 AM.png
 
Tim Curtis said:
Interesting config.

I haven't played around with OTG host mode but maybe I'll find some spare cycles.

If setting MPD to 32 bit format works to eliminate the audio glitches then FYI you can set this in the MPD Config Screen and avoid having to manually edit mpd.conf.

View attachment 537109
Click to expand...
I would not have guessed that this is where I needed to set it. I'd been manually updating mpd.conf on each restart. Thanks!

I tested this fix for sometime now. The CPU does not seem more stressed with the larger 32-bit frames. Gapless playback continues to work.
 
You must log in or register to reply here.

Similar threads

J
Eversolo-screen: display what your Eversolo is playing on your TV (Raspberry Pi and IR remote control)
Replies
1
Views
386
JulienFromParis
J
L
Raspberry Pi 5 Lyrion server/player plus network share
Replies
0
Views
372
linuxfan
L
MadEnvel
Kalinka — lightweight, modular streaming software for DIY and embedded audio projects
Replies
1
Views
300
MadEnvel
MadEnvel
Sasha Masand
SROVA: Linux-based headless hi-res player beta for NUC/PC and Raspberry Pi
2
Replies
20
Views
2K
Sasha Masand
Sasha Masand
G
RPi5 + CamillaDSP help needed
Replies
16
Views
2K
mdsimon2
M
Back
Top Bottom