.deb to optimize Linux Mint (Debian) for Audio Pro

[Sthauge]

I use a script that disable HT when Jack starts and enable HT when Jack stops.

That could be helpful to share for a few people if you can.

Sure, here's the script:

#!/bin/bash
typeset -i core_id
typeset -i sibling_id
typeset -i state

for i in /sys/devices/system/cpu/cpu[0-9]*; do
core_id="${i##*cpu}"
sibling_id="-1"

if [ -f ${i}/topology/thread_siblings_list ]; then
sibling_id="$(cut -d',' -f1 ${i}/topology/thread_siblings_list)"
fi

if [ $core_id -ne $sibling_id ]; then
state="$(<${i}/online)"
echo -n "$((1-state))" > "${i}/online"
echo "switched ${i}/online to $((1-state))"
fi
done

Put it in a txt fil. Change the number "9" in this line "/sys/devices/system/cpu/cpu[0-9]" to your processor number of threads + 1. Name the txt file eg. HT_On_Off.sh and use command: sudo HT_On_Off.sh to execute it.

The script will flipp/flopp HT on/off.

[keefaz]

That sounds great. Would you be willing to share the script?

Sure...

Code:

#!/bin/bash

set_cpugovernor() {
    local SCALING_GOVERNOR=$1
    
    sudo echo $SCALING_GOVERNOR | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
    
    if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then
        echo "Enabled CPU frequency scaling governor:  $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"
    fi
}

set_performance() {
    echo "Set cpu scaling governor to performance"
    set_cpugovernor performance
}

kill_pulse() {
    echo "Stop pulseaudio server"
    echo "autospawn = no" > $HOME/.config/pulse/client.conf
    pulseaudio --kill
}

realtime_start() {
    echo "Tuning realtime IRQ threads"

    # adapt this line for your distro
    sudo /etc/rc.d/rc.rtirq start
}

reset_performance() {
    echo "Set cpu scaling governor to powersave"
    set_cpugovernor powersave
}

start_pulse() {
    echo "Start pulseaudio server"
    if [ -f $HOME/.config/pulse/client.conf ]; then
        rm $HOME/.config/pulse/client.conf
    fi
    pulseaudio --start
}

realtime_stop() {
    echo "Reset realtime IRQ threads"

    # adapt this line for your distro
    sudo /etc/rc.d/rc.rtirq reset
}

case "$1" in
'start')
  kill_pulse
  set_performance
  realtime_start
  echo "System has been setup for realtime audio"
  ;;
'stop')
  start_pulse
  reset_performance
  realtime_stop
  echo "System reset to non realtime audio"
  ;;
*)
  echo "Usage: $0 start|stop"
esac

Note: This script is for Slackware distro which use the /etc/rc.d system init script, you will have to adapt for your system regarding the rc.rtirq script invocation

[Sthauge]

Note: This script is for Slackware distro which use the /etc/rc.d system init script, you will have to adapt for your system regarding the rc.rtirq script invocation

I use it on Kubuntu and it work as expected, so I guess it's Ok with Ubuntu type of distros. How it work together the .deb package in this thread I don't know. Feel free to modify it and repost it.

[keefaz]

I use it on Kubuntu and it work as expected, so I guess it's Ok with Ubuntu type of distros. How it work together the .deb package in this thread I don't know. Feel free to modify it and repost it.

You meant your script works in Kubuntu, right?
Mine invokes rtirq script which is in /etc/rc.d in Slackware
I think in Ubuntu, it should be in /etc/init.d instead
https://wiki.ubuntu.com/UbuntuStudio/rtirq

[Sthauge]

You meant your script works in Kubuntu, right?

Yes, that's correct

[ethanay]

EG there is a strong case for disabling hyperthreading during low latency audio work, but it generally makes sense to keep it enabled.

No it's not.

There is no argument here. I said it makes sense to disable it for low latency work, and (to clarify, outside of low latency audio usage scenarios) it generally makes sense to keep it enabled. IE when you aren't using the computer for audio production work, it makes slightly more sense to have it enabled.

IMO, most people won't see much of a difference by having SMT disabled all the time, and they'll feel the difference even less, unless they are doing a lot of compiling / transcoding / etc, but even then that is usually a "walk away, take a break" sort of scenario, or switch tasks, where you aren't so concerned whether a process finishes 15 seconds early or late, and the difference is usually more subtle. Not sure if SMT plays a role in keeping a computer more responsive while CPU intensive processes operate in the background, perhaps that is an argument for enabling it.

SMT does help with the race to sleep philosophy of power/performance optimization, although that philosophy directly conflicts with low latency audio setup work, anyway. Changes in power states are usually measured in ms, not us. No modern processor can undergo a change in power state fast enough to prevent either xruns or massive increases in latency.

The other side-benefit of keeping SMT disabled if you aren't so concerned with the inane "speed wars" of the Benchmark People is that it increases security and reduces the overhead of having to implement the side channel attack mitigations, as with SMT disabled, there is only one lord of the FPU chip per core, and he shares power with no one So you can't get exploited with a side channel attack, and your FPU on each core doesn't get hammered with unnecessary context switches from a competing "virtual core" relying on the same hardware.

It's the old "throughput vs latency vs power" debate -- pick any two

[Sthauge]

EG there is a strong case for disabling hyperthreading during low latency audio work, but it generally makes sense to keep it enabled.

No it's not.

We do not disagree on this, but I understand your first sentence different from what was your intent to say. I understand it like: could be ok to disable HT, but in general it is no need to disable HT doing audiowork.

You'll also see in my other post that I disable HT when doing audio work and enable HT when doing work like eg. word processing.