Yes. Most importantly
1. If possible install a RT linux kernel
realtime Linux Kernel - ?
EDIT:
wiki.linuxaudio.org
2:
Theoretically rt means less performance. Generally for max performance you want max buffering and for rt you want zero buffering.
True. But Pipewire is where the buffer sizes are set. The only thing I'm changing is normal kernel vs the -rt kernel, which uses the PREEMPT_RT config.
I'm not talking about pipewire buffers, but about everything else too. If a system wants real time capabilities it should sacrifice any pipelining.
Hmm. I understand that in theory. But in practical performance terms there appears to be something wrong with the Debian -rt kernel config. I'm testing the Liquorix and Xanmod RT kernels with this exact same setup and they perform very well.
It is not that there is something wrong with the Debian real time kernel. You are comparing apples and oranges. Most of the tweaks to the two custom kernels that you were talking about don't have anything actually to do with real time settings anymore. They stick with the outdated naming because of how much information on the internet leads people astray to assuming that they need a real-time kernel in order to achieve low latency work.
Thanks, that actually does make sense according to my testing. When trying to push the limits even more of lowest latency + highest throughput this is what I found, ranked from best to worst (#4 and #5 are much worse):
- Xanmod (non-RT)
- Liquorix
- Debian standard
- Xanmod-rt
- Debian-rt
Exactly, the 2 that beat stock Debian are making the last few mods that haven't been applied to the standard kernel yet.
The primary reason these other mods haven't been applied is that they have either not been thoroughly tested enough to prove that they are safe for typical users, or if there are known issues, they are not easy to mitigate.
And, since the difference in performance is real but small, I am erring on the safe side and trusting the standard kernel
Yeah, I agree that those mods are probably not ideal for a general purpose kernel. The gains are minimal anyway, what really makes a huge difference is 1) Tweaking Pipewire or Jack for low latency (I strongly prefer Pipewire myself) and 2) many of the configurations recommended
here.
I am using Pipewire's Virtual ALSA device because it allows me the most control while embracing the future (Pipewire) over the past (JACK).
I love everything that JACK enabled. I am truly grateful for the work the devs put into it. But, at this point, it makes sense to acknowledge that the future is Pipewire.
And, I agree. The rtcqs tweaks are the bomb!!
For me the best thing about Pipewire is its native integration of PulseAudio + JACK protocols. I used to spend an inordinate amount of time trying to bridge the two together with very hackish methods that were prone to failure, and JACK was hard to configure to the latency requirements. With Pipewire I just have to change a single quantum setting to get the low latency that I need, and apps that need PulseAudio just work together with the others that think they're using JACK.
I used Erick Eickmeyer's Ubuntu Studio Tools (now just StudioTools) to configure JACK+Pulse. I usually found that the .deb for the most recent Ubuntu LTS would work for Debian (sacrilege, I know).
I kept doing that until I was confident that I could reproduce my workflow in Pipewire directly. Discovering the Virtual ALSA devices were just icing on the cake.
Unfortunately, most of the online advice you will read about using real-time kernels for audio production are very outdated. Most of the tweaks that were important for low latency work, originally exclusive to real-time kernels, have been migrated to the mainstream kernels.
Real time does not equal low latency in general. The best uses for the remaining features exclusive to real-time kernels are not the ones that overlap with low latency applications.
Anyone who is being honest about their own actual evaluations will agree with the account that you have documented here.
