Moode Audio Player for Raspberry Pi

Jump to Latest
#16,162
J Epstein said:
OK, new problem. USB extrernal drive connected directly to the pi by cable. When formatted ext4, it shows up in the list of USB mounts, but no files are read into the library. When the same drive is reformatted exFAT, there are files visible.

Any ideas?
Click to expand...
Prolly permissions. I have several systems with ext4 USB and NVMe disks and no issues whatsoever.
https://mpd.readthedocs.io/en/stable/user.html#database
 
  • Like
Reactions: J Epstein
#16,163
OK! Thank you Tim!

Permissions started as:

drwx------ 5 jeremy jeremy 4096 Jun 6 21:58 ext4thumb

chown & chmod got me to:
drwxr-xr-x 5 root root 4096 Jun 6 21:58 ext4thumb

Then guess what happened?

Yup. New library entries.

How can I make this automatic/persistent? Say I take my 4TB drive which I had formatted as exFAT while troubleshooting and reformat it ext4 - will I need to do this terminal surgery every reboot or will the permission and owner change stick?

Does the owner need to be root root? Or will 755 permissions on jeremy jeremy be enough?

I know almost enough to be dangerous, go slow....
 
#16,165
Then your configuration is incorrect.

The link I sent you has more links.

Not only must the USB connection be made - to enable the data link- but the transport layer must also be configured. When you mount the drive you can specify the filesystem type... you would need some means of automatically identify the filesystem type when the USB device is identified and connected.

In the short term, just use exFAT formatting and/or try manually mounting the drive. See if you can get that working first.... then you will need to see how to make so it will self mount when you plug it in via USB.

I created a Raspberry 5 last year, with the defaults, and I have no trouble mounting and seeing ext4 filesystems when I plug in a USB stick.
 
#16,166
flex2 said:
@tonyEE.
... You really need to try it and don't just base your opinion on what you "think" is the right answer based on principles.
Click to expand...

LOOK, it's not what I feel, it's not theoretical principles, it is how it works internally. It's called analysis based on Computer Engineering Architecture.

It's not what I think, it's what we were measuring (in this case measurements make sense) when we ran the AXI, AHB and even the PCI bus.... I spend years with my nose stuck on the debuggers and the development tools.

If Nelson Pass tells you something about an analog amp you listen to him because that's his experience. If he says the issue is not in his amp, you believe him, right?

If you bought a cell phone ( Android or Apple ) in the late teens with a BCM SoC then you were hardware designed with some of my device drivers. Of course, I was only one of a hundred of R&D engineers and, unlike Nelson, my work is covered by NDAs to the hilt. Pretty much my colleagues over at Qualcomm, Apple, Nokia, Samsung, etc... were all doing the same thing!

We used Palladium emulators to verify the RTL design, with really fancy debuggers and a Lauterbach JTAG debugger as well. When we taped the design and got the silicon back, we used more ARM debugging tools and the JTAG debugger.

Spent months.. heck years, specially as I actually wrote the code and the stress tests for the DMA, which meant I was using all kinds of peripherals that fed the modem, the network and the multimedia modules... yep... that meant the digital audio interfaces such as I2s (someone else in my team wrote that driver, but we were running all kinds of stress tests on the design... worst case test cases, with the smallest buffers you can imagine... which were forcing the streamer software to make lots, LOTS of frequent requests for data..). Heck our job was to stress the device to find out its limits and corner cases... and we NEVER saw a buffer size cause any kind of drop outs or change in the sound quality of the DAC renderer. Never saw any jitter at the DAC (which was our own RTL IP in the SoC).

We were running this in our SoCs, and our Raspberries (2s and 3s then). Using bare metal, ThreadX and Android (kernel).

The ONLY way you could ever see a buffer issue is if someone had written really, REALLY bad streamer code that run in a loop, main thread, in the kernel. Something that would break the deterministic behavior of the cores. Something that a High End audio company might do because they're CHEAP when it comes of the firmware, which is very expensive to develop... specially for low volume products.

However, I have not seen anyone write such crappy streamer software in an Open Source distro as they would be laughed out from the Open Source project to begin with.

If you drain an buffer in a transmission chain, you will end up with drop out... audio, video, data, cell voice... etc.

+++

OK, forget the jitter... what could be happening?

So.... when you are changing the size of buffers... take a look in more detail at what buffers you are really changing... There could be internal streaming buffer that if they run down, they force the really badly designed streamer software to repeat the same sample... it could be... that would be terribly bad software design.... And, combined with this, you could have a really, truly bad streaming source with really narrow and/or bursty bandwidth... so that if your buffers are too small, you are draining them and your bad software is repeating some samples so as to not stop the DAC from stopping the sound...

A corner case of bad design with insufficient network capacity that ignores Quality Of Service.

But these things have nothing to do with the jitter... none at all.

+++

What kind of a source are you using for your audio? A 28K modem? 802.11b with several devices? Your problem is NOT jitter in the I2S or anywhere within the Raspberry. It could be upfront.

Try a different datalink for your streamer. Try a robust, high bandwidth source... say a USB stick reading a file. See if the data buffers make any difference. Do not run any other application software when you do this.

..

BTW, have you ever played with something like Tidal? If you are running on streaming from the network, if you lose the connection, it stops the music. If you had a huge buffer at the network front end, it might allow you to handle the network timeouts.... but this has NOTHING to do with jitter.
...

That's pretty much it...
 
Last edited:
  • Like
Reactions: PMental
#16,167
TonyEE, many thanks for a lengthy, respectful and clear post.
Appriciate your knowledge and are happy that someone with real knowledge try to understand what I'm talking about.

Please understand that I really hear these differences in sound quality. Once heard, it's impossible to neglect the fact. I simply can't.
It takes approx 1 second for the MPD to restart so it's well within the timeframe of what is considered to be the limit of human's audio memory.
I can identify and in detail describe for you how the sound changes for Input cache and Audio Buffer. Changes in output buffer are hardly detectable.

I doubt that I have a bandwidth problem.
I have 100/100 Mbit/s fiber connection to my ISP, and can measure around 70-80 MBit/s with other devices connected to my WiFi network.
I can run Raspberry Pi with 5GHz connection and it measures a quality of 87% and -49dBm. Mixed auto select 802.11a/n/ac and I think ac is used.
I rarely get any interuptions because of my network capacity.
Tried Tidal, but prefer HiRez Qobuz as streaming service. Max resolution I use from Qobuz is 24 bit 96kHz since that is the maximum my Mark Levinson 360s DAC can handle. So in general max 3 Mbit/s streaming.

The changes in audio quality is instant when changes are made and don't change over time so I can not support the idea that it should be a connectivity issue.

Despite your deep knowledge I urge you to test yourself.
I can hear it and I suppose you can too if your audio gear is on the same level as mine. High level Stax rigs.

Regarding Nelson Pass, yes, of course I would listen to him if he say's that the problem isn't in his amplifier since he knows it best and in general design excellent and high quality products that mostly sound excellent too.
So do I, a I share a lot of Nelson's views of what will make a good amplifier and how to tune an amplifer to sound good.

Please don't tell me that I can't possibly hear what I hear. I do, but I can not understand why, and as it seems you can't eigther based on your experience.
I can only urge you to really test it, and I can send you one of my setups of Raspberry Pi + Allo DigiOne if you honor to send it back when finished testing.
 
Last edited:
#16,168
Hi,

moOde 9.3.6 is available in the Media Player OS section of the Raspberry Pi Imager or as a direct download at https://moodeaudio.org. Visit the Forum for more information https://moodeaudio.org/forum/showthread.php?tid=7758&pid=64198#pid64198

moode-r900-logotype-bg.png
 
  • Like
  • Thank You
Reactions: Deenoo, J Epstein and flex2
#16,169
flex2 said:
TonyEE, many thanks for a lengthy, respectful and clear post.
Appriciate your knowledge and are happy that someone with real knowledge try to understand what I'm talking about.

Please understand that I really hear these differences in sound quality. Once heard, it's impossible to neglect the fact. I simply can't.
It takes approx 1 second for the MPD to restart so it's well within the timeframe of what is considered to be the limit of human's audio memory.
I can identify and in detail describe for you how the sound changes for Input cache and Audio Buffer. Changes in output buffer are hardly detectable.

I doubt that I have a bandwidth problem.
I have 100/100 Mbit/s fiber connection to my ISP, and can measure around 70-80 MBit/s with other devices connected to my WiFi network.
I can run Raspberry Pi with 5GHz connection and it measures a quality of 87% and -49dBm. Mixed auto select 802.11a/n/ac and I think ac is used.
I rarely get any interuptions because of my network capacity.
Tried Tidal, but prefer HiRez Qobuz as streaming service. Max resolution I use from Qobuz is 24 bit 96kHz since that is the maximum my Mark Levinson 360s DAC can handle. So in general max 3 Mbit/s streaming.

The changes in audio quality is instant when changes are made and don't change over time so I can not support the idea that it should be a connectivity issue.

Despite your deep knowledge I urge you to test yourself.
I can hear it and I suppose you can too if your audio gear is on the same level as mine. High level Stax rigs.

Regarding Nelson Pass, yes, of course I would listen to him if he say's that the problem isn't in his amplifier since he knows it best and in general design excellent and high quality products that mostly sound excellent too.
So do I, a I share a lot of Nelson's views of what will make a good amplifier and how to tune an amplifer to sound good.

Please don't tell me that I can't possibly hear what I hear. I do, but I can not understand why, and as it seems you can't eigther based on your experience.
I can only urge you to really test it, and I can send you one of my setups of Raspberry Pi + Allo DigiOne if you honor to send it back when finished testing.
Click to expand...


Hmm... my systems are of sufficiently high quality that I would hear issues... Let's no open up that can of worms.

Trouble shoot.

Verify all your cabling.

Verify your power supplies.

Update the software you're using.

Do not run anything else on your Raspberry.

Connect to your Raspberry with a nice GigE connection.

Try a different DAC running a USB connection.

Use a hard drive as source of your music files.

If you have a spare Raspberry, try using that one.

Trouble shoot. Isolate the source of the problem.

At some point you will not hear the difference.

Currently I use my Raspberries for control with a relay hat, NAS and for development ( vi, gcc, make, grep, find.... ). For my streamers, nowadays, I use the USB interface. I migrated to the Wiim Ultra as a bridge between GigE/WiFi to USB. Bit perfect playback from Android/Chromebook/WIndows without any issues.
 
#16,171
Absolutely TonyEE
Actually there is no problem at all.
I'm extremely happy with the sound from my Raspberry Pi and Allo DigiOne.
It plays fantastic with the DAC I'm using, and I'm overall very pleased with how Qobuz and Moode work.
I just shared what I found regarding the cache, buffers and clock settings.
A few people didn't like that and attacked me as if I was an idiot.
I'm far from an idiot and have experience enough to be able to keep me from falling into traps regarding how to listen and measure.

I have an Allo Signature DigiOne + a better power supply on it's way to me so I at least can test some of your suggestions.
Maybe I will find something out, but I really do not need to. My streaming device are in many ways better than my CD/SACD players and vinyl rig.
Cheap solution, but absolutely on par with a lot of very expensive high end gear that visited my system.

Just wanted to share and help other to get the most out of their Moode streamer.

Thanks for your suggestions, I will try what I can.
 
  • Like
Reactions: Botte, Deenoo and barryso
You must log in or register to reply here.
Top Bottom