Sound Config moOde 7

[zOr7gA8]

also you can play around with modifying this option in mpd.service:

Code:

CPUSchedulePolicy=other

here you can try fifo instead of other, or try values explained in the file.

Code:

CPUSchedulingPriority=43

you can go higher. just try out.

Code:

Nice=-10

you can go lower.

This two configs only has effects depending on chosen Policy as described in file.

After you changed mpd.service it is enough to restart mpd and daemon, but a reboot works too ;-)

Code:

sudo systemctl daemon-reload
sudo systemctl restart mpd

Kind regards, Martin

[Manni]

Hi Manfred,


for running mpd-service in isolated cores you have to add something in cmdline.txt and modify mpd.service

Code:

sudo pico /boot/cmdline.txt

add in this line:

Code:

isolcpus=2,3

modify mpd.service

Code:

sudo pico /lib/systemd/system/mpd.service

modify the line

Code:

ExecStart=/usr/local/bin/mpd --no-daemon $MPDCONF

to

Code:

ExecStart=/usr/bin/taskset -c 2,3 /usr/local/bin/mpd --no-daemon $MPDCONF

save all changes you made and reboot.

Hi Martin, 

thx a lot for the quick reply.

isolcpus=2,3 = means only core 1 & core 2 are running and core 3 & 4 are off?

[energyi]

So what is the verdict? Do these mods make a noticable difference? Thanks for any constructive discussion.

[Manni]

So what is the verdict? Do these mods make a noticable difference? Thanks for any constructive discussion.

Only did the isolation of the cores so far. 
There is a change, but I can not tell now, if I like or dislike.

I typically leave my audio system untouched after a change for several days to get used to „this“ sound signature. Only then I judge it by either keep it or my brain doesn’t like it and I go back.

[zOr7gA8]

isolcpus=2,3 = means only core 1 & core 2 are running and core 3 & 4 are off?

This isolates the cores 3 and 4 from the system, so main system doesn't use them. The other command in mpd.service connects this process to the isolated cores, so it is maybe running faster/better.

@energyi
It is an older way of sound tuning to reduce latency. Audible effects are more subtle in vers 7 than vers 6, I think. At least it depends on your system and your personal favour.

Kind regards, Martin

[morehifi]

how is your config? did you change something? do you use Edwards Tweak?
mpd.service -config?

I start with same config as moOde 6. but do not hear a difference.

Hi,

I also tried to isolate two cpus for using them with squeezelite only.
Therefore I modified /boot/config.txt and added:

Code:

isolcpus=2,3

after rebooting my pi I checked if the isolation is in place. But it wasn't

Code:

cat /sys/devices/system/cpu/isolated

I then added the isolation kernel parameter "isolcpus=2,3" to /boot/cmdline.txt

Code:

cat /boot/cmdline.txt

net.ifnames=0 isolcpus=2,3 console=serial0,115200 console=tty1 root=PARTUUID=067e19d7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

And voila

Code:

cat /sys/devices/system/cpu/isolated
2-3

It worked.
Next I changed some parameters in /lib/systemd/system/squeezlite.service

Code:

CPUSchedulingPolicy=fifo
CPUSchedulingPriority=70
CPUAffinity=2,3
Nice=-18

(no need to add "/usr/bin/taskset - c 1,3". if you use the CPUAffinity parameter)

Restarted the service

Code:

sudo systemctl daemon-reload
sudo systemctl restart squeezlite

... and the sound is now definitely better (and it was already very good!)

MoodeAudio: 7.01
RaspPI: 4

[TheOldPresbyope]

Once again I'll preface my post with "I'm not here to argue for or against tweaks" but this time I want to clear up an apparent misunderstanding concerning the Linux concepts of isolcpus and taskset.

isolcpus

This is a kernel parameter and this is the definition of it from kernel.org/doc/v5.4/admin-guide/kernel-parameters.html

Code:

isolcpus=       [KNL,SMP,ISOL] Isolate a given set of CPUs from disturbance.
                       [Deprecated - use cpusets instead]
                       Format: [flag-list,]<cpu-list>

                       Specify one or more CPUs to isolate from disturbances
                       specified in the flag list (default: domain):

                        nohz
                          Disable the tick when a single task runs.

                          A residual 1Hz tick is offloaded to workqueues, which you
                          need to affine to housekeeping through the global
                          workqueue's affinity configured via the
                          /sys/devices/virtual/workqueue/cpumask sysfs file, or
                          by using the 'domain' flag described below.

                          NOTE: by default the global workqueue runs on all CPUs,
                          so to protect individual CPUs the 'cpumask' file has to
                          be configured manually after bootup.

                        domain
                          Isolate from the general SMP balancing and scheduling
                          algorithms. Note that performing domain isolation this way
                          is irreversible: it's not possible to bring back a CPU to
                          the domains once isolated through isolcpus. It's strongly
                          advised to use cpusets instead to disable scheduler load
                          balancing through the "cpuset.sched_load_balance" file.
                          It offers a much more flexible interface where CPUs can
                          move in and out of an isolated set anytime.

                          You can move a process onto or off an "isolated" CPU via
                          the CPU affinity syscalls or cpuset.
                          <cpu number> begins at 0 and the maximum value is
                          "number of CPUs in system - 1".

                        The format of <cpu-list> is described above.

Oops. Deprecated? Yup, and has been for some time. However, as can be seen in the syntax definition, the flag-list is optional and the default results in the same behavior as in older kernels, e.g., "Isolate from the general SMP balancing and scheduling algorithms". Hence it still works, at least for now.

So, when one uses isolcpus=2,3 then only cpus 0 and 1 (assuming the RPi model in question has 4 cpus) can be assigned processes in a normal way by moOde/RaspiOS. On the other hand, cpus 2 and 3 will be used if and only if processes are manually assigned to them.

It appears to me in reading this forum thread that the first part of this concept is well understood but that the implication of being isolated from the balancing and scheduling algorithms is not as well understood.

taskset

From the man page for this command (reformatted to fix this forum page)

Code:

DESCRIPTION
      taskset  is  used to set or retrieve the CPU affinity of a running process given its
      pid, or to launch a new command with a given CPU affinity.  CPU affinity is a
      scheduler property that "bonds" a process to a given set of CPUs on the system.
      The Linux scheduler will honor the given CPU affinity and the  process  will  not
      run  on  any  other  CPUs.   Note that the Linux scheduler also supports natural
      CPU affinity: the scheduler attempts to keep processes on the same CPU as long as
      practical for performance reasons.  Therefore, forcing a specific CPU affinity is
      useful only in certain applications.

As noted by another in a previous post, using this command is equivalent to specifying CPUAffinity in the service file. Either way, there is a not-subtle difference between using a cpu range here when the isolcpus= parameter is not used and when it is used.

1. not used: The scheduler will honor the taskset cpu range. Suppose taskset=2,3. Then the specified process (and all the threads it may spawn) will only ever run on cpu 2 or cpu 3. If more than one process has the same assigned cpu range, then the scheduler/balancer will distribute them across the range as their algorithms dictate.
   
2. used: Suppose, again, taskset=2,3 but this time isolcpus=2,3 is also used. Then the specified process (and all the threads it may spawn) will only ever run on cpu 2. If more than one process has the same assigned cpu range, then they will all only ever run on cpu 2. Remember, these cpus have been isolated so the scheduler/balancer algorithms never see how they are being used or not used. 
   

One practical implication of this for our example case is that cpu 3 is never used (except for the inevitable kworker processes which get started on every cpu). That's 25 percent of the total cpu capacity. Even more is lost because the other isolated cpu likely is lightly loaded by the few processes which can run on it. 

Another practical implication is that all the remaining processes are thrown onto cpu 0 and cpu 1, essentially doubling their loads. On a typical RPi4B moOde installation, I've found that each of the 4 cpus is running approximately 35 processes, albeit not necessarily all active at once. With 2 cpus isolated, on the other hand, the remaining two cpus are each running approximately 70 processes. Whether this introduces new performance issues depends on the overall usage.

Bottom line:

If you must isolate a process using this deprecated technique, then I suggest you try using isolcpus=3 and taskset=3. If you want to isolate two processes, each to its own cpu, then try using isolcpus=2,3 while using taskset=2 for one process and taskset=3 for the other.

Regards,
Kent

PS - the purpose of this post is only to clarify Linux. I don't wish to discuss fine tuning either the deprecated technique or the cpusets alternative. Consult your favorite search engine.

[vinnn]

I have tried MANY tweaks with Moode 7 and have spent days trying different combinations. After all was said and done, I have to admit that standard Moode 7 sounds excellent. I made a lot of tweaks to 6.7 and Moode 7.01 sound just as good as 6.7 WITH all of my tweaks.

Ultimately the ONE tweak that I would recommend for Moode 7 would be to isolate CPU cores, but the core numbers DO make a difference (don't want to argue this, if you can't hear a difference then I am jealous of you).

First, make sure that you are set to 32-bit Kernal Architecture under System. Under MPD options, make sure everything is left stock and SoX is turned off. Previously with 6.7 SoX needed to be ON in order to sound good, but Moode 7 sounds better without it now.

Then under SYSTEM go to SSH Term Server and open the Terminal.

Login is Pi and Password is Moodeaudio.

Type in

Sudo Pico /boot/cmdline.txt

add the line: isolcpus=1,3

I add it at the end right before rootwait.

Hit Ctrl-X and save changes by pressing enter.

THEN go to MPD Service

Sudo Pico /lib/systemd/system/mpd.service

Go down to #Launch Params

Add the line: /usr/bin/taskset - c 1,3

So it should look like this: ExecStart=/usr/bin/taskset - c 1,3 /usr/local/bin/mpd -- no - daemon $MPDCONF

Do a CTRL-X and save changes by pressing enter.

Then get out of the terminal and restart the system.

Remember, isolate cores 1 and 3, not 2 and 4. Don't ask me why because I don't know why it sounds different, but it is very subtle.

-Allen

This will only serve to make your Raspberry Pi generally perform a bit worse, CPU scheduling and general operating system settings will have no effect on how PCM data is converted into an analogue signal. Aside from any resampling and eq you may be applying after decoding the only thing that determines how your music sounds before going into your amplifier is the DAC circuit.

[WuBai]

Vinnn,


Without a doubt you are correct on one point, these settings will make the Raspberry Pi perform worse computationally.  But what impact a hamstrung Raspberry Pi has on the audio is another question altogether.  I found on the older version of Moode that lowering the CPU frequency as well as the memory frequency had an impact on the sound.  Now, I'm not here to tell you it had a better or worse impact, but it had an impact in my system.  I believe this thread was started where the OP was asking a similar question to gauge if and to what degree 'tweaks' made an impact in Moode 7.  I don't believe it was the OPs intention of going down the path of claiming that no changes other than EQ settings make the slightest impact.  The OP and I may have a system different than yours or may be cursed with either extremely acute hearing or also may just actually be clinically insane and actually hear differences, sometimes stark differences.

Personally in my experience, I have found that 'everything' makes an impact on the sound.  The AC receptacle, power cord type, bypass capacitors, DC connector type, literally every single thing in the entire system has an impact on the sound, both before and after the DAC.  Even the type of circuit breaker you have in your loadcenter and the bus configuration has an impact.  But again, I'm not here to make any declarations for others or say 'this has an impact and this doesn't.'  I'm here to provide my experience, taken with a grain of salt, and allow for people who wish to experiment to do so and make up their own minds. 

There is much in the world of audio that hasn't been studied, and that is part of what makes it such an interesting hobby.  Obviously this leads to a lot of interesting conversations between Computer Science Majors and double PHDs in Electrical Engineering with every single measuring device known to man claiming that wire is wire, a capacitor is a capacitor and a resistor is a resistor and that people who change them with different varieties are throwing their money away and only believe the sound changes due to psychological confirmation bias.  The same holds true to Raspberry Pi based streamers, since this is a fairly new phenomenon in terms of audio.  

I fully respect your opinion and do not wish to change it in any way.  If you wish to experiment and hear no difference, then truly I envy you because you've just eliminated many variables on your quest to audio nirvana.  If you do not wish to experiment to find if there is an impact, then I fully respect that path as well.

-Allen

[zOr7gA8]

good position. but isocpus=1,3 doesn't make sense at all.