Moode 7.01 does not start on newest RPi 4 8GB RAM

[TheOldPresbyope]

Sorry, I hadn’t had my morning coffee yet. Perversely, it calms me (which probably means I’m addicted to it!). 

Honestly, though, combing through code while pondering hypotheticals seems akin to debating how many angels can dance on the head of a pin.

Today’s a national holiday here. I’m trying to decide whether to brave the crowds and the humidity or play with the proposed Bluetooth SBC XQ/XQ+ mod. Probably some of both

Regards,
Kent

[Nutul]

Sorry, I hadn’t had my morning coffee yet. Perversely, it calms me (which probably means I’m addicted to it!).

That's what happens to me as well :-)

Now, back to the system load...
I have tried to read every line of the release notes on Git2, from 7.0.1 to 8.3.3, and despite there are a lot of improvements and new services available (mount points monitor to name one... but can be toggled) I cannot see anything that would result in CPU overload.

Could it be that some specific DAC driver / overlay is misbehaving, but not to the extent to immediately show up like rendering the unit mute, or crashing it?

I must say that I have always had moOde running either on a Pi3 or 4, and switching to the 4 the major improvement for me has been the more responsive UI, as I use the local 7'' display.

Also, having a nvme drive over USB 3 makes things very fast, but for what concerns SQ I strongly believe it can make any difference, apart from being eventually faster at loading the first track into the MPD cache.

[TheOldPresbyope]

CPU overload should lead to such things as MPD reporting buffer underrun errors, errors which are immediately apparent in drop-outs, clicking, and so on. [1]

What I have trouble with is exemplified by this report (from a user whose opinion I trust) in @Edward's HowTo: Instruction Guide Sound Tweaks Now on GitHub

The soundstage just opened up, with better localisation and a lot of more details. Sound get tighten up and is much more controlled.

I don't know how to relate any of these qualifiers to lines of code in moOde/Raspberry Pi OS nor how to test for success.

Thankfully, I'm quite happy with what I have.

Regards,
Kent


[1] Even the MPD devs felt the need to weigh in on the related topic of real-time scheduling. From the MPD User's Manual

Note

There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load.

[Tim Curtis]

@Tim Curtis

out of curiosity, what might be the overall increase of "things" running in the background in the past two / three years or so, which could result in an increased system load?

The playback pipeline hasn't changed since the very first release of moOde almost 10 years ago. It's still just MPD -> ALSA -> Device. It's also the same Web Stack (PHP/NGINX/Sqlite) that provides the WebUI and the same job processing daemon (worker.php) for handling config changes. Processor load during playback on an out-of-the-box, no features enabled system today is same as in the past and is around 1% on multi-core Pi's.

Turning various features on for example any of the Renderers, Auto-shuffle, SoX, CamillaDSP, Local Display etc results in their processes being loaded and executed and system load increasing accordingly.

Here are some system load examples from 3 of my systems all of which deliver fantastic sound quality for me :-) While the results below are typical I've run much higher loads on these systems up to 90% CPU utilization in some cases when experimenting and no change in sound quality whatsoever.

These systems are all running: moOde 8.3.3 | Linux: 6.1.21-v8+ #1642 | aarch64 (64-bit) | RaspiOS: 11.7

System 1
--------
Model: Pi-4B 1.1 2GB
Audio: Allo Revolution DAC
Features enabled:
- None
pi@sig:~ $ moodeutl -m
CPU: 1.5 GHz, LOAD: 1% 48C | MEM: 10% used | DISK: 10% used, 26G free | PHP: 4 workers

System 2
--------
Model: Pi-3B+ 1.3 1GB
Audio: ProtoDAC TDA1387 X8
Features enabled:
- CamillaDSP, MPD/CamillaDSP volume proxy, Auto-shuffle, Mount Monitor, Airplay, Bluetooth 
pi@moode:~ $ moodeutl -m
CPU: 1.4 GHz, LOAD: 3% 52C | MEM: 27% used | DISK: 10% used, 26G free | PHP: 5 workers

System 3
--------
Model: Pi-3B+ 1.3 1GB
Audio: ProtoDAC TDA1387 X8
Features enabled:
- CamillaDSP, MPD/CamillaDSP volume proxy, Auto-shuffle, Mount Monitor, Airplay, Local Display
pi@kef:~ $ moodeutl -m
CPU: 1.4 GHz, LOAD: 7% 51C | MEM: 45% used | DISK: 10% used, 26G free | PHP: 6 workerss

Regarding tweaks and sound quality:

The assertion by some that system load or OS tweaks affect sound quality is patently false because there is simply no hard evidence to support those claims. By hard evidence I'm not referring to someone else's "ears", I mean detailed data and signal traces that others can scrutinize and use to try and reproduce and confirm the claims. But of course these bogus claims keep popping up on audio Forums because they appeal directly to the nature of audio enthusiasts to want to tweak things.

I should mention that there is one case where system load does in fact affect sound quality and that is when the load is extreme for example a pegged CPU (100% utilization). In that case there will be long (in CPU time) interruptions in the processing of audio data in the pipeline and thus the continuous flow of audio data is interrupted and audible glitches are produced that also show up on signal traces and typically correlate directly to buffer underrun entries reported in logs.

My advice when considering any assertion by someone that this or that OS tweak improves sound quality is to ask them for the hard evidence. Don't just accept their claim at face value, and remember that the mind is easily influenced by false assertions especially if they cooporate with biases toward those assertions that an indivual may already have.

I should also remind everyone that moOde including it's component parts are all Open Source which means that you can freely examine and analyze the source code and see for yourself exactly how everything works and whats happening to the audio data. If you find any defects in the code affecting audio data report them and if they are credible they will be investigated.

[Nutul]

That's exactly what I was able or, better, unable to detect: a (more or less) constant increase in running services during the years.


It will possibly remain so for the next 10, uh...?

[Convert]

Hi All and apologies for the delayed response. I agree with Tim and many others who say that as long as the information is in digital format no sound quality can be lost as it is always 1 and 0 and when a 1 is lost it is re-read and corrected. Only when converted to analog sound quality can be lost.

However what bugs me for years: why is so much energy spend on digital devices to keep SQ high when the cheapest hardware and the bulkiest operation system does not matter? Why Apple products for example, famous for digital quality in video and sound for years?

[Tim Curtis]

Hi All and apologies for the delayed response. I agree with Tim and many others who say that as long as the information is in digital format no sound quality can be lost as it is always 1 and 0 and when a 1 is lost it is re-read and corrected. Only when converted to analog sound quality can be lost.

However what bugs me for years: why is so much energy spend on digital devices to keep SQ high when the cheapest hardware and the bulkiest operation system does not matter? Why Apple products for example, famous for digital quality in video and sound for years?

You may want to revisit your assumptions.

Digital audio signals can be distorted by timing errors, electromagnetic interference (noise) and software/hardware bugs all of which would be evident by examining signal traces or the software code containing the bug.

Digital audio data is transmitted between the source (renderer) and the destination (audio device) using Isochronous transfer mode which has no error detection/correction mechanism because its sole purpose is to deliver data at a desired rate.

This is in contrast to Bulk data transfer mode which is used for transferring file data and has error detection/correction, retransmit and guaranteed delivery or fail. Another way to look at it is that for file transfer whats most important is that the data is unaltered and that each transfer of a chunk of data completes successfully not how long the transfer takes. For audio data whats most important is that the desired data rate is maintained not whether a bit here or there might be dropped.

For example bulk data transfer is used for getting an audio file from your NAS or attached USB drive to the player software's input buffer. Isochronous transfer is use to get the decoded PCM data from the player to the audio device across a USB or I2S interface.

What about getting audio data from a remote source to the player software's input buffer across a network? This is done using so called "streaming" protocols. Some operate more like Bulk data transfer and others more like Isochronous transfer. In practice which operational mode is used doesn't matter.

Claims that the OS or playback software introduces distortion in the audio data needs to be accompanied by proof that shows the distortion in a signal trace and identifies exactly what in the code is causing the distortion otherwise consider the the claims to be bogus.

[Convert]

[quote pid='47799' dateline='1690471430']
Claims that the OS or playback software introduces distortion in the audio data needs to be accompanied by proof that shows the distortion in a signal trace and identifies exactly what in the code is causing the distortion otherwise consider the the claims to be bogus.
[/quote]
Hi Tim, thanks for explaining. I am a sole listener and can not compete with the technical background you have.

What I understand from your explanations is that SQ can suffer on the digital side and not only after converted to analog. This explains why I can hear a difference although using the same hardware just with another version of Volumino or Moode.

Now, I have not the technical knowhow to measure this, sadly. And what could be measured, really. What makes the data show better separation of instruments in the room, for example? Impossible I guess.

Thanks to everybody

[Tim Curtis]

[quote pid='47799' dateline='1690471430']
Claims that the OS or playback software introduces distortion in the audio data needs to be accompanied by proof that shows the distortion in a signal trace and identifies exactly what in the code is causing the distortion otherwise consider the the claims to be bogus.

Hi Tim, thanks for explaining. I am a sole listener and can not compete with the technical background you have.

What I understand from your explanations is that SQ can suffer on the digital side and not only after converted to analog. This explains why I can hear a difference although using the same hardware just with another version of Volumino or Moode.

Now, I have not the technical knowhow to measure this, sadly. And what could be measured, really. What makes the data show better separation of instruments in the room, for example? Impossible I guess.

Thanks to everybody

The technical part is not really whats important in my posts its more the message that while obviously distortion can be introduced in the audio software pipeline, it can be measured and it's root cause can be identified and fixed. There is no such thing as "invisible distortion" or "invisible sound wave changes".

As far as hearing a difference in sound characteristics goes, either there is an actual difference in the sound waves being rendered which will show up in a signal trace, i.e., in the data, or the difference is perceptual and only exists in the mind.

Without any data to back up your report of hearing a difference and attributing it to something in the softwares its not possible too know whether what you are hearing is real or perceived.

ETA: When I refer to differences in sound or sound waves, signal traces, data, distortion, etc there is no attempt to qualify the difference in terms of "sound quality" because there's metric for sound quality.

[Convert]

Tim said: The technical part is not really whats important in my posts its more the message that while obviously distortion can be introduced in the audio software pipeline, it can be measured and it's root cause can be identified and fixed. There is no such thing as "invisible distortion" or "invisible sound wave changes".

As far as hearing a difference in sound characteristics goes, either there is an actual difference in the sound waves being rendered which will show up in a signal trace, i.e., in the data, or the difference is perceptual and only exists in the mind.

After establishing that there a things able to change the SQ in the digital path, and in my case the hardware / environent is not changed, what could be used to measure the data stream to compare those different Volumino / Moode versions? Of course, I know it can be all only on my mind and how subjective we humans are, but since you say it could be measurable, could we do it?