Hello everyone,
I recently answered the threads topic question for me recently and want to share my results to give people a recent experience.
The overall result is that XRUNS are reduced to zero.
TL;DR: Changing JUST the used kernel (from Debain 10 stock to the Liquorix low-latency kernel) helped to get down from occasional xruns (single or a flood) on my machine with the jack settings 128 frames / 3 periods to zero xruns tested for much more than just 10 minutes while Pulseaudio is bridged to jack.
THE DETAILS (I hope their verbosity is not annoying anyone):
I read a lot about other peoples experiences and went down to tracing my stock kernel. Here is what I’ve done and what it resulted in:
Action: Wifi turned off Result: seems to not reduce xruns
Action: Swappiness from 60 to 10 Result: seems to not reduce xruns
Action: CPU governer to power Result: seems to not reduce xruns
Action: limits.conf/audio.conf Result: seems to not reduce xruns
Action: Changed priorities of apps in system monitor Result: Might reduce xruns to a half (not tested in depth)
Action: Threaded IRQ enabled Result: seems not to reduce xruns
Action: Change (test all) USB 2 ports instead of a USB 3 port Result: seems not to reduce xruns
Action: Stop all docker containers Result: seems not to reduce xruns
Action: Installed and enabled a realtime kernel Result: seems not to reduce xruns, but introduces high system load (130+ %)
Action: Tested Quartett audio interface Result: seems not to reduce xruns
Action: Used X instead of Wayland Result: seems not to reduce xruns
Action: Stopped all software in jack to test stability in general Result: seems not to reduce xruns
Action: Disabling EIST in BIOS Result: seems not to reduce xruns
Action: Using liquorix low latency kernel Result: reduces xruns (while halfing the frames per period and using pulseaudio) (tested for multiple sessions for at least an hour each)
Maybe it is interesting to know that all actions I’ve done have been reverted if there was no success. So when I say it is JUST the liquorix kernel then it is just that that has been changed. As a side note: I use Cadence and Claudia from the KxStudio repositories with standard settings (No realtime priority changed or something else - except of the frames / priod and periods of course).
TEST SETUP
- JACK runs with about 5 ms (256 frames / 3 periods)
- CPU governor performance
- CPU frequency boost enabled
- Ardour connected in jack and playing a mix
- Guitarix running
- Musescore connected in jack playng a loop
- Pulseaudio unbridged from jack
- QLC running
- aubiotrack running
- ALSA Midi bridge active
This setup was used for all tests.
Since there were no xruns using the Liquorix kernel I tried to reproduce some xruns by cutting the the frames per period in half (to 128 frames / period) AND connecting Pulseaudio to jack. This setup also succeeded and showed no xruns.
TEST DEPTH
This setup (I reduced the number of programs running in jack because I don’t need all of them at once and since I tested the Action: “Stopped all software in jack to test stability in general” and it did not reduce xruns reducing programs should not reduce xruns - CPU governor was also reverted back to power saving since this also didn’t help and saves energy) has been tested about five to ten times now for a duration of at least one hour each - some sessions were about two to three hours and there were no xruns (which were not related to rare programs actions. aubiotrack for example ALWAYS causes xruns when it is shut down - I do not take these xruns into account)
THE TEST SYSTEM
Ignore the used stock kernel below. I use the standard kernel for normal (this) work. Liquorix low-latency kernel is only used for audio sessions. (No good reason for that - I just want it that way)
Yes I run two docker containers for nextcloud.
tobias@tobias-pc:~$ inxi -Fx
System: Host: tobias-pc Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Gnome 3.30.2
Distro: Debian GNU/Linux 10 (buster)
Machine: Type: Desktop Mobo: MSI model: Z77A-G41 (MS-7758) v: 3.0 serial: BIOS: American Megatrends v: 2.13
date: 03/07/2014
CPU: Topology: Quad Core model: Intel Core i5-3570K bits: 64 type: MCP arch: Ivy Bridge rev: 9 L2 cache: 6144 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27201
Speed: 2290 MHz min/max: 1600/3800 MHz Core speeds (MHz): 1: 2290 2: 2495 3: 2449 4: 2672
Graphics: Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: ASUSTeK driver: nouveau v: kernel bus ID: 01:00.0
Display: wayland server: X.Org 1.20.4 driver: nouveau resolution: 1920x1080~60Hz
OpenGL: renderer: NV124 v: 4.3 Mesa 18.3.6 direct render: Yes
Audio: Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel
bus ID: 00:1b.0
Device-2: NVIDIA GM204 High Definition Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 01:00.1
Device-3: VIA VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio driver: snd_ice1724 v: kernel bus ID: 05:00.0
Device-4: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder vendor: Hauppauge works WinTV HVR-4000-HD
driver: cx8800 v: 1.0.0 bus ID: 05:01.0
Device-5: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] vendor: Hauppauge works
driver: cx88_audio bus ID: 05:01.1
Device-6: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port]
vendor: Hauppauge works WinTV HVR-4000-HD driver: cx88-mpeg driver manager bus ID: 05:01.2
Device-7: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder [IR Port]
vendor: Hauppauge works WinTV HVR-4000-HD driver: N/A bus ID: 05:01.4
Device-8: Focusrite-Novation type: USB driver: snd-usb-audio bus ID: 1-1.4:5
Sound Server: ALSA v: k4.19.0-6-amd64
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Micro-Star MSI driver: r8169 v: kernel
port: d000 bus ID: 03:00.0
IF: enp3s0 state: down mac: […]
Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k v: kernel port: c000 bus ID: 06:00.0
IF: wlp6s0 state: up mac: […]
IF-ID-1: br-37c90329cb87 state: up speed: N/A duplex: N/A mac: 02:42:70:93:01:3e
IF-ID-2: docker0 state: down mac: 02:42:fa:fd:35:01
IF-ID-3: veth864d9cd state: up speed: 10000 Mbps duplex: full mac: 36:7a:06:c3:06:00
IF-ID-4: vethacab615 state: up speed: 10000 Mbps duplex: full mac: 3e:57:55:86:bc:98
Drives: Local Storage: total: 1.03 TiB used: 789.87 GiB (75.2%)
ID-1: /dev/sda vendor: Samsung model: SSD 840 PRO Series size: 119.24 GiB
ID-2: /dev/sdb vendor: Seagate model: ST1000DM005 HD103SJ size: 931.51 GiB
PS: Tracing the kernel showed there are latencies, but I was unable to find the root cause for the latency. Since the low latency kernel works much better Iassume my system has no hardware or IRQ issues. If that is true then the latency in the stock kernel might be just caused by a normal scheduling latency. So I guess that finding the cause for the stock kernel latency would not have get me any further.
Best wishes to everyone - let me know if there are any discrepancies in my explanation.