Unexpectedly high xruns with modern hardware
Moderators: MattKingUSA, khz
Unexpectedly high xruns with modern hardware
I've got an i5-9600KF CPU @ 3.70GHz (6 cores) with an M-Audio M-track solo interface that shows up in lsusb as "Texas Instruments PCM2900C Audio CODEC."
I'm running at a sample rate of 48,000/second. When I set JACK's buffer size to 128 bytes, I start seeing several underruns per second. If I go down to 64 byte buffers, xruns go through the roof. Even with the buffer size set to 256, my audio still occasionally gets choppy.
I'm launching JACK through Cadence, and I do have realtime checked (priority 10). uname -v reports #1 SMP Debian 5.10.28-1 (2021-04-09). I do use the pulseaudio bridge to get sound to web browsers and non-music stuff, so pulseaudio is usually running. It's not in the path for any of the things I care about here though.
My window manager is fluxbox, and I've had audio get choppy when the only things I'm running are Cadence, Catia, and pavucontrol.
Just running audio straight from the interface to my speakers, 128-byte buffers show steady xruns with occasional choppiness in the audio and 64-byte buffers give a high rate of xruns and completely unusable sound.
The DSP load as reported by Catia hovers around 7 or 8% with CPU below 10% while my buffer size is 128 and xruns climb rapidly. At 256-byte buffers, it's pretty steady at 4% DSP load.
I've been using Debian for around 20 years, but never for real-time stuff. Is there something I should do to configure the system better in order to be able to use smaller buffers? Is this a problem with my audio interface or its drivers? It's usable with 256-byte buffers, and 10ms is not the end of the world, but I feel like this machine ought to be able to do a lot better.
I'm running at a sample rate of 48,000/second. When I set JACK's buffer size to 128 bytes, I start seeing several underruns per second. If I go down to 64 byte buffers, xruns go through the roof. Even with the buffer size set to 256, my audio still occasionally gets choppy.
I'm launching JACK through Cadence, and I do have realtime checked (priority 10). uname -v reports #1 SMP Debian 5.10.28-1 (2021-04-09). I do use the pulseaudio bridge to get sound to web browsers and non-music stuff, so pulseaudio is usually running. It's not in the path for any of the things I care about here though.
My window manager is fluxbox, and I've had audio get choppy when the only things I'm running are Cadence, Catia, and pavucontrol.
Just running audio straight from the interface to my speakers, 128-byte buffers show steady xruns with occasional choppiness in the audio and 64-byte buffers give a high rate of xruns and completely unusable sound.
The DSP load as reported by Catia hovers around 7 or 8% with CPU below 10% while my buffer size is 128 and xruns climb rapidly. At 256-byte buffers, it's pretty steady at 4% DSP load.
I've been using Debian for around 20 years, but never for real-time stuff. Is there something I should do to configure the system better in order to be able to use smaller buffers? Is this a problem with my audio interface or its drivers? It's usable with 256-byte buffers, and 10ms is not the end of the world, but I feel like this machine ought to be able to do a lot better.
- sunrat
- Established Member
- Posts: 919
- Joined: Wed Jul 22, 2020 2:08 pm
- Has thanked: 151 times
- Been thanked: 244 times
Re: Unexpectedly high xruns with modern hardware
I tried Debian's default kernel with JACK for audio a while ago and it was pretty bad. Try a Liquorix kernel and optimise your system by following the linuxaudio.org wiki system configuration guide. Particularly run the RealtimeConfigQuickScan script and follow its suggestions. A realtime kernel is not essential except for specific use cases.
For Intel I found disabling C-states, and threadirqs kernel parameters to be helpful. I wrote a guide to setting up Bullseye and, although aimed for KDE, many tips would be universal for Debian; it's in the Tips and Tricks section.
I presume you are using Bullseye as that kernel you mentioned is the current one.
For Intel I found disabling C-states, and threadirqs kernel parameters to be helpful. I wrote a guide to setting up Bullseye and, although aimed for KDE, many tips would be universal for Debian; it's in the Tips and Tricks section.
I presume you are using Bullseye as that kernel you mentioned is the current one.
- TAERSH
- Established Member
- Posts: 455
- Joined: Mon Feb 03, 2020 6:48 pm
- Has thanked: 27 times
- Been thanked: 21 times
Re: Unexpectedly high xruns with modern hardware
How would anyone check for?
My Music:
https://soundcloud.com/user-633698367
The Seventh of Eight Vol.2:
https://soundcloud.com/user-633698367/s ... ight-vol-2
https://soundcloud.com/user-633698367
The Seventh of Eight Vol.2:
https://soundcloud.com/user-633698367/s ... ight-vol-2
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: Unexpectedly high xruns with modern hardware
Use groups :TAERSH wrote:How would anyone check for?
Code: Select all
$ groups
realtime audio neo
Code: Select all
@audio - rtprio 95
@audio - memlock unlimited
Re: Unexpectedly high xruns with modern hardware
Ahah, for some reason I had assumed that realtime stuff had crept into the stock Debian kernel when I wasn't paying attention. Thanks for the pointer to RealtimeConfigQuickScan. I'll let you know how it works out.
Re: Unexpectedly high xruns with modern hardware
Well, it turns out my video drivers are incompatible with realtime kernels, and I use this system for gaming. So instead of coming up with some dual boot hackery, I dusted off an old mac mini that's been lying around unused for at least 5 years, installed Debian with 5.10.0-6-rt-amd64, kxtools, plugged my audio interface into it, and now I can run with 64-byte buffers and no glitches.
Bonus: it can sit right next to the drums so I don't have to run a bunch of cables across the room. Plus, headless means even lower overhead from no X server. Next up: shorter cables.
Thanks for the pointers.
Bonus: it can sit right next to the drums so I don't have to run a bunch of cables across the room. Plus, headless means even lower overhead from no X server. Next up: shorter cables.
Thanks for the pointers.
- sunrat
- Established Member
- Posts: 919
- Joined: Wed Jul 22, 2020 2:08 pm
- Has thanked: 151 times
- Been thanked: 244 times
Re: Unexpectedly high xruns with modern hardware
That's partly true, Debian's RT kernels and most others won't allow Nvidia drivers to build. Arch and Manjaro have a specially patched RT kernel that does work with Nvidia drivers. I installed Manjaro especially to check this out but for my use it wasn't any better than my current Debian Bullseye using the Liquorix low-latency kernel with Debian's nvidia-driver package. I don't do any serious MIDI stuff with it though which is where an RT kernel helps most.
Congratulations on your new xrun-free setup!
-
- Established Member
- Posts: 2347
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 466 times
Re: Unexpectedly high xruns with modern hardware
I'm using the Nvidia driver with a rt-kernel since years now on my debian/sid system without issues.
True, I'm used to build my own kernels so I don't know if that works with a stock debian rt-kernel as well.
On the road again.
- sunrat
- Established Member
- Posts: 919
- Joined: Wed Jul 22, 2020 2:08 pm
- Has thanked: 151 times
- Been thanked: 244 times
Re: Unexpectedly high xruns with modern hardware
Didn't build modules last I tried it although I don't usually build kernels. I did try it once but...
Time to try again, stay tuned!
Edit, later - @tramp I just installed the latest Debian RT kernel 5.10.0-6-rt-amd64 on Bullseye (my second sacrificial install for just such occasions); didn't build nvidia. I can send you the make.log if you're interested. I'm sure many Debian users would be in rapture to be able to use nvidia with that kernel.
I've seen many posts on various forums saying it can't be done. Even the make.log says so:
Code: Select all
The kernel you are installing for is a PREEMPT_RT kernel!
The NVIDIA driver does not support real-time kernels. If you
are using a stock distribution kernel, please install
a variant of this kernel that does not have the PREEMPT_RT
patch set applied; if this is a custom kernel, please
install a standard Linux kernel. Then try installing the
NVIDIA kernel module again.
*** Failed PREEMPT_RT sanity check. Bailing out! ***
-
- Established Member
- Posts: 2347
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 466 times
Re: Unexpectedly high xruns with modern hardware
The Nvidia driver build script have a environment variable, you could set
before build, or just
Code: Select all
export IGNORE_PREEMPT_RT_PRESENCE=1
Code: Select all
make IGNORE_PREEMPT_RT_PRESENCE=1
On the road again.
- sunrat
- Established Member
- Posts: 919
- Joined: Wed Jul 22, 2020 2:08 pm
- Has thanked: 151 times
- Been thanked: 244 times
Re: Unexpectedly high xruns with modern hardware
Building nvidia driver from source would be a new learning experience for me but I will give it a go. Are you suggesting to build from the Debian nvidia-kernel-source package? I always just installed the nvidia-driver package which builds module automatically with dkms.
Why does the PREEMPT_RT check exist if the driver builds on RT without it?
Why does the PREEMPT_RT check exist if the driver builds on RT without it?
-
- Established Member
- Posts: 2347
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 466 times
Re: Unexpectedly high xruns with modern hardware
you could just use the debian package. When the build fail, run export IGNORE_PREEMPT_RT_PRESENCE=1 and rebuild the driver (apt install -f), or check in the terminal the make command the driver use, copy it over and add IGNORE_PREEMPT_RT_PRESENCE=1 to the make line.
I don't know for sure, but as far I remember it's because the Nvidia driver using some symbols which are marked as GNU under the rt-kernel. You are not allowed to share the resulting binary.
But, I may be totally wrong with my remind.
I don't know for sure, but as far I remember it's because the Nvidia driver using some symbols which are marked as GNU under the rt-kernel. You are not allowed to share the resulting binary.
But, I may be totally wrong with my remind.
On the road again.
- sunrat
- Established Member
- Posts: 919
- Joined: Wed Jul 22, 2020 2:08 pm
- Has thanked: 151 times
- Been thanked: 244 times
Re: Unexpectedly high xruns with modern hardware
Got there in the end. Thanks so much for your guidance @tramp ! It was easier than I initially envisioned.
What worked (Liquorix kernel was active with nvidia-driver package already installed when I did this):
- export IGNORE_PREEMPT_RT_PRESENCE=1
- run the make command from failed make.log
- reinstalled RT kernel and headers to install module (not sure if this is correct but I think module didn't install otherwise. apt install -f did nothing)
- reboot into RT kernel
I really don't know much about doing this stuff but am not afraid to try things and break things. I created a backup with fsarchiver prior to doing it.
What worked (Liquorix kernel was active with nvidia-driver package already installed when I did this):
- export IGNORE_PREEMPT_RT_PRESENCE=1
- run the make command from failed make.log
- reinstalled RT kernel and headers to install module (not sure if this is correct but I think module didn't install otherwise. apt install -f did nothing)
- reboot into RT kernel
I really don't know much about doing this stuff but am not afraid to try things and break things. I created a backup with fsarchiver prior to doing it.
Code: Select all
$ inxi -CGS
System: Host: bullseye-studio Kernel: 5.10.0-6-rt-amd64 x86_64 bits: 64 Desktop: KDE Plasma 5.20.5
Distro: Debian GNU/Linux bullseye/sid
CPU: Info: Quad Core model: Intel Core i5-6500 bits: 64 type: MCP L2 cache: 6 MiB
Speed: 3307 MHz min/max: 800/3600 MHz Core speeds (MHz): 1: 3307 2: 3300 3: 3300 4: 3300
Graphics: Device-1: NVIDIA GM204 [GeForce GTX 970] driver: nvidia v: 460.73.01
Display: x11 server: X.Org 1.20.11 driver: loaded: nvidia
unloaded: fbdev,modesetting,nouveau,vesa resolution: 3840x2160~30Hz
OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 460.73.01