System DSP load in Debian 12

[Babarosa]

Recently (viewtopic.php?t=27121) there was a discussion about optimizing latency configuration on an audio PC.
Contrary to that thread, I am neither using pipewire nor pulseaudio but ALSA and JACK.

I tested kernel "optimizations" suggested by this website https://samiux.github.io/low_latency.html against the unedited file "etc/default/grub" by playing a complex song in Rosegarden sequencer consisting of several MIDI-, Audio-, Wave- and LV2-Synth-Tracks. The system performs rock solid and I do not get x-runs.

1.) "Not optimized"
When using my vanilla kernel "linux-image-6.1.0-28-rt-amd64" without any optimizations the DSP load reported by QJackCtl was from 12 to 15%.
The corresponding line in grub was "GRUB_CMDLINE_LINUX_DEFAULT="quiet"".

2.) "Optimized"
After a reboot and the exactly same conditions the DSP load reported by QJackCtl was from 16 to 20%.
The corresponding line in grub was "GRUB_CMDLINE_LINUX_DEFAULT="preempt=full nohz=on nohz_full=all threadirqs rcu_nocbs=all rcutree.enable_rcu_lazy=1 quiet splash""

So, I wonder are these "optimizations" any good or does the rt-kernel already include everything needed?

[sunrat]

For an RT kernel, I believe preempt=full and threadirqs are already specified in kernel build config so would do nothing in grub options. I use a Liquorix kernel with options:

Code: Select all

quiet intel_idle.max_cstate=0 processor.max_cstate=1 threadirqs mitigations=off

Full options shown (some of these are inbuilt to the kernel):

Code: Select all

cat /proc/cmdline
audit=0 intel_pstate=disable  BOOT_IMAGE=/boot/vmlinuz-6.10.9-1-liquorix-amd64 root=UUID=<redacted> ro quiet intel_idle.max_cstate=0 processor.max_cstate=1 threadirqs mitigations=off

I tested some nohz options with no effect on this kernel, haven't tried the other options you have. Several are specific to Intel of course.

I just did a mix project here - viewtopic.php?t=27583 - with 36 tracks and about 99 plugins. DSP shown in Ardour was over 50% but no xruns except for when I did something stupid. Quite impressed with my 9 year old system, a Core i5 6500 with 16GB RAM and 1TB SATA SSD.

If you have the right optimisations they can definitely have a significant effect. Finding the right ones is the key. I spent some time several years ago testing different options before settling on these.

[tseaver]

@Babarosa

I tested kernel "optimizations" ... by playing a complex song in Rosegarden sequencer consisting of several MIDI-, Audio-, Wave- and LV2-Synth-Tracks. The system performs rock solid and I do not get x-runs.

FWIW, playing back recorded audio / MIDI is not the use case most people have in mind when they talk about "low latency" audio work: there isn't any external source to keep in sync, and so you can leave the number of samples per period high (e.g., 1024) without noticing anything. What most folks think of is recording live played audio / MIDI while a) monitoring the performance through software, or b) trying to keep the recorded performance "in sync" (in the performer's ears) with previously recorded material.