Sound Tweak Rpi4

[philrandal]

https://github.com/philrandal/Linux-Audio-Adjustments

Does anyone have any experience with this?

Oops, I'd forgotten to apply those changes to my own two Moode players which I'd rebuilt for 6.6.

Phil

[grasshopper]

Hello,
I am pretty new to Rpi and moodeaudio. I tried to summarize and combine different tweaks (thanks to all contributors) to optimize the sound of my Rpi which is connected to an external USB DAC. I have get a pretty good sound with these tweaks and settings:

1 – isolating procs
added in /boot/cmdline.txt: isolcpus=2,3

sudo pico /lib/systemd/system/mpd.service
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=70
Nice=-16
ExecStart=/usr/bin/taskset -c 2,3 /usr/local/bin/mpd --no-daemon $MPDCONF

2 - config.txt
sudo nano /boot/config.txt

arm_freq=1000
sdram_freq=2000
core_freq=500
gpu_freq=500
over_voltage=-5
over_voltage_sdram=-5
gpu_mem=16 
max_usb_current=1
force_turbo=1
initial_turbo=60
avoid_pwm_pll=1

3 - configure moode
SOX 32/352,6 medium
64 bits


This is a first share on my side. May be you can as specialists improve these settings.
Best,

I've seen the tweaks in other posts in SQ. Did you add them sequentially or all at once? What sound improvements do you ascribe to each setting? I have never tried 1 or 2 (don't want to break Moode), but I'm a believer in SoX. Prefer very high quality setting. I've tried medium, and definitely prefer VHQ. I think SoX greatly improves 3D. Previously had RPi3B+ Allo Boss. Now have USB DAC SMSL Sanskrit MkII. Getting pops with SoX. Lose the 3D benefit without SoX. Assuming that I need to upgrade to RPi4.

This is based on the same posts you mention, and I tried to optimize sequentially for the pi4.
Beginning with the config-file: overall, little improvements in all dimensions (details, scene etc.)
Then the procs: next level of improvement. Much better details and 3d. Very close to the quality of my CD player. With the parameter Nice=15-18, you can adjust the brightness pretty well to your taste.
I prefer SOX medium in my setup, somewhat more musical in the mids and highs.
Last I set 64 bits with moode 6.6: more clarity and details.

Overall I am happy with this setup.

More clarity & detail from using the 64bit kernel?  I admit I have never tried the 64bit kernel in moOde on the basis that even with that kernel, the userland remains 32bit, so I am surprised there is any change to the sound.
Can you expand on what you mean by clarity & details please?

[swizzle]

My two cents...

The 64-bit kernel allows kernel tasks to be preempted which allows for much lower latency. This is basically what the 3.x “real time” kernel options did. Note that mpd is still a little squirrelly with the 64-bit kernel but switching over once your setup is finished should be fine.

The other tweaks... I used to be a believer but haven’t bothered lately. If you feel like it makes a positive difference then that’s what matters.

[Tim Curtis]

The cmds below print which preempt options were selected to build the kernel

Code:

sudo modprobe configs
zcat /proc/config.gz | grep PREEMPT

This article explains the options
https://www.codeblueprint.co.uk/2019/12/...ghput.html

[TheOldPresbyope]

And my three cents...

1/ The TCP and UDP throughput experiments in the referenced article are a poor proxy for what we really want to know: are the data samples delivered in sufficient time for the DAC to process without introducing additional audible artifacts? I say additional because a DAC always introduces artifacts. That's why some of us dote on the curves posted, for example, in audiosciencereview.com.

Delivering individual samples in sufficient time is different from sample throughput. Think of cars on a highway: asking how many cars pass a checkpoint in an hour is different from asking how uniformly spaced the cars are when they pass.

The working definition of "real time" in the software industry. is: can the required function be completed within the required time interval? The MPD docs contain an interesting comment regarding this point: 

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.

2/ The referenced article explored the effect of a set of kernel-build parameters, not the difference between a 32-bit kernel and a 64-bit kernel.

Where's the data comparing the two kernels as well as the three parameters? Where's the data comparing the 5.4.x kernel against the 4.19.x kernel? (That was my life as an experimental physicist/engineer. There's always another experiment to be done.)

For that matter, where's the counterpart data for the PREEMPT_RT parameter setting? The article promises it in the comments but the answer is MIA.

As well, If setting CONFIG_PREEMPT is an unalloyed good, then one has to wonder why the "official" 32-bit Raspbian kernel isn't built with it set? I suspect the maintainers themselves are in disagreement over the choices.

3/ There's a reason the 64-bit kernel is still not part of the Raspberry Pi OS release and hence is still a testing option in moOde. Look at the relevant github repos and forums. Subtle gotchas are still being worked out in the kernel modules, the drivers, the interface between kernel space and userland.

Tim's code is hostage to the entire userland and kernel space stack. I suspect it will be some time yet before the dust has settled on the kernel space code. Then's there's the coming conversion of the userland code in Raspberry Pi OS to 64-bit. That'll be exciting!

Bottom line on the 64-bit kernel: Try it. It's free. You might like it. You might not. You might even not notice you switched. Just don't hit Tim over the head with it!

Regards,
Kent

[Tim Curtis]

What would be nice is to see a time stamped trace of sample frames within the OS showing some that sort of timing issue, frame loss, etc actually exists. Then it could be analyzed to see what's causing the problem.

Anyway, my point in posting about latency is to provide info from an engineers point of view which leans heavily on testing and analysis :-)

The 32 bit kernels are compiled with CONFIG_PREEMPT_VOLUNTARY=y

Code:

pi@rp3:~ $ uname -a
Linux rp3 5.4.49-v7+ #1323 SMP Fri Jun 26 14:34:26 BST 2020 armv7l GNU/Linux
pi@rp3:~ $ sudo modprobe configs
pi@rp3:~ $ zcat /proc/config.gz | grep PREEMPT
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPTIRQ_TRACEPOINTS=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

The 64-bit kernels are compiled with CONFIG_PREEMPT=y

Code:

pi@rp3:~ $ uname -a
Linux rp3 5.4.49-v8+ #1323 SMP PREEMPT Fri Jun 26 14:47:11 BST 2020 aarch64 GNU/Linux
pi@rp3:~ $ sudo modprobe configs
pi@rp3:~ $ zcat /proc/config.gz | grep PREEMPT
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPTIRQ_TRACEPOINTS=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set

[hestehandler]

To get anywhere on this topic there would need to be ABX testing performed of two similar Raspberries, both feeding a DAC that can cater two inputs, then double-blind and randomised audition one unmodified Pi against the other Pi with modified parameters. Anything else is confirmation bias, wishful thinking, and placebo.

[Tim Curtis]

Sure you could do listening tests but that not going to tell you whether the audio sample frames traveling within the OS are undergoing some sort of timing or data corruption, and if they are then what's causing it.

[TheOldPresbyope]

To get anywhere on this topic there would need to be ABX testing performed of two similar Raspberries, both feeding a DAC that can cater two inputs, then double-blind and randomised audition one unmodified Pi against the other Pi with modified parameters. Anything else is confirmation bias, wishful thinking, and placebo.

I used to believe that. More accurately, I still believe it but I no longer believe that publishing the results of such work will automatically convince others. Sometimes even the people who participated in the trial disagree vehemently with the conclusions drawn from it. We're all human.

Still, the numbers have to come first for me.

What would be nice is to see a time stamped trace of sample frames within the OS showing some that sort of timing issue, frame loss, etc actually exists. Then it could be analyzed to see what's causing the problem.

Anyway, my point in posting about latency is to provide info from an engineers point of view which leans heavily on testing and analysis :-)

Should be obvious I agree.

Regards,
Kent

[hestehandler]

I used to believe that. More accurately, I still believe it but I no longer believe that publishing the results of such work will automatically convince others. Sometimes even the people who participated in the trial disagree vehemently with the conclusions drawn from it. We're all human.

I know the type. These people can not be helped by reason, so there is no sense in trying. However there are those of up that are audiophiles, but not audiofools.