Sound Tweak Rpi4

[sjoerdju]

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

Does anyone have any experience with this?

I do; I make these adjustments every time I install a new version of Moode. Results in a small but noticeable improvement in audio quality, IMO, on my system. I expect that most people would not hear any difference, unless they have a very high resolution audio system, so YMMV. It's easy enough to try out.

I can second this, FWIW.

[hifinet]

I tried the philrandal tweak with SoX 32/394 VHQ, and my initial impression is that the sound is cleaner and more focused, but more recessed with smaller soundstage. Uninstalled it, and I actually prefer the larger soundstage. It's a tradeoff. More clarity, focus and detail or increased soundstage. Reminds me of the Nelson Pass distortion generator. Most people prefer a little out of phase second harmonic distortion, which adds some depth and soundstage to create the illusion of live music. Creating an illusion is what it's all about. Moode 6.6.0 is excellent.

Pass BAF 2018 video

[swizzle]

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

The case against preempt is it hurts performance a bit, the voluntary setting seems like a good compromise especially for older hardware. The Pi 4 can afford to give up a few cycles, especially in an audio context where the processor isn’t working very hard and the newer processor might not suffer as much of a perf hit. 

Back when the linked tweaks were under a different name I thought they helped when running the 32-bit kernel but were counterproductive with the newer mpd versions and/or 64-bit kernel (can’t remember the timeline, it was one of them though). It was never a big difference in any case. I used to underclock and do the other type of tweaks until I complained once to Tim about library loading being slower in a test version and tracing the difference to those changes. It had a pretty noticeable impact and any sound improvement was very minor so I stopped bothering when I moved to the Pi 4. I might try the non-config.txt ones again out of nostalgia.

[philrandal]

The case against preempt is it hurts performance a bit, the voluntary setting seems like a good compromise especially for older hardware. The Pi 4 can afford to give up a few cycles, especially in an audio context where the processor isn’t working very hard and the newer processor might not suffer as much of a perf hit. 

Back when the linked tweaks were under a different name I thought they helped when running the 32-bit kernel but were counterproductive with the newer mpd versions and/or 64-bit kernel (can’t remember the timeline, it was one of them though). It was never a big difference in any case. I used to underclock and do the other type of tweaks until I complained once to Tim about library loading being slower in a test version and tracing the difference to those changes. It had a pretty noticeable impact and any sound improvement was very minor so I stopped bothering when I moved to the Pi 4. I might try the non-config.txt ones again out of nostalgia.

The tweaks were @dynobot's.

I just refactored his script to make it more readable and use unique files for the tweaks.  His original stuff is now back up on github.

On a Pi 3B, I still hear a difference, but I haven't tracked down which of those changes is responsible.

As one of those still working through lockdown, I have had limited opportunity to play with this.

On my hardware (see my sig) 64-bit kernel, sox 32/384 highest quality sounds best to my ears.

Phil

[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

The case against preempt is it hurts performance a bit, the voluntary setting seems like a good compromise especially for older hardware. The Pi 4 can afford to give up a few cycles, especially in an audio context where the processor isn’t working very hard and the newer processor might not suffer as much of a perf hit. 

Back when the linked tweaks were under a different name I thought they helped when running the 32-bit kernel but were counterproductive with the newer mpd versions and/or 64-bit kernel (can’t remember the timeline, it was one of them though). It was never a big difference in any case. I used to underclock and do the other type of tweaks until I complained once to Tim about library loading being slower in a test version and tracing the difference to those changes. It had a pretty noticeable impact and any sound improvement was very minor so I stopped bothering when I moved to the Pi 4. I might try the non-config.txt ones again out of nostalgia.

I remember that ;-)

What might be possible is to create a "System tuning" panel that consolidates a reasonable set of options in one place.

More feedback would be needed on this.

[philrandal]

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

The case against preempt is it hurts performance a bit, the voluntary setting seems like a good compromise especially for older hardware. The Pi 4 can afford to give up a few cycles, especially in an audio context where the processor isn’t working very hard and the newer processor might not suffer as much of a perf hit. 

Back when the linked tweaks were under a different name I thought they helped when running the 32-bit kernel but were counterproductive with the newer mpd versions and/or 64-bit kernel (can’t remember the timeline, it was one of them though). It was never a big difference in any case. I used to underclock and do the other type of tweaks until I complained once to Tim about library loading being slower in a test version and tracing the difference to those changes. It had a pretty noticeable impact and any sound improvement was very minor so I stopped bothering when I moved to the Pi 4. I might try the non-config.txt ones again out of nostalgia.

I remember that ;-)

What might be possible is to create a "System tuning" panel that consolidates a reasonable set of options in one place.

More feedback would be needed on this.

CPU isolation and deliberate underclocking (on the pi 4 only?) are two interesting avenues which might be worth exploring.

Playing with "nice" figures might be useful too.

Phil

[hifinet]

Tim Curtis Wrote:

What might be possible is to create a "System tuning" panel that consolidates a reasonable set of options in one place.

Sounds like a great idea. I was just about to ask how one would apply the tweaks individually, such as 'Improving Network Latency'. I am not familiar with Linux command line.

[Tim Curtis]

I wouldn't mess with the Linux network stack, it's reliable, robust and perfectly fine as-is.

The vast majority of network issues IME are due to poorly configured wireless LAN's, WiFi band interference, poor NAS or network device throughput, other hardware/firmware issues etc. All these issues are external to the Linux net stack.

[TheOldPresbyope]

Somehow the idea of exposing an "advanced tweaks" page reminds me of the busy box I made to keep my kids out of my hair when they were young. A bunch of dials and switches and lights and gauges, oh, my. 

[Tim Curtis]

Not "advanced tweaks" but "reasonable set of options". There's some things already in moOde for "tuning and experimenting" including the cpu governor, 32/64 bit kernel and mpd git compiles. Maybe thats enough but it would be interesting to hear what people think would be useful and most importantly why.