Debugging Xruns

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Post Reply
alex
Established Member
Posts: 6
Joined: Fri May 08, 2020 5:13 am

Debugging Xruns

Post by alex »

I have a few simple questions about debugging xruns. I'm relatively new to the pro-audio world but have been working with Linux for years. I'm running Ubuntu Studio 20.04 on a 2014 ThinkPad with a Focusrite Scarlett 18i8. Kernel version 5.4.0-29-lowlatency and using primarily Ardour5.

My xrun woes have come in 3 flavors. The first seems solved, the second is a problematic mystery, and the third is a less critical conundrum. To get concrete:
  1. Right out of the box the 18i8 worked in terms of basic functionality. Off the bat I encountered xruns frequenty, one or two at a time, but I quickly came across these instructions (big thanks to raboof and whoever else helped compile that page - it was super helpful). Running through a number of those steps seems to have eliminated these frequent low-level xruns, sans 1 or 2 at startup.
  2. Where things get more problematic is that every once in a while I'll encounter a huge burst of xruns. Ardour will freeze, all the audio will cut off, and it'll start racking up xruns, ~10-50 per second. Sometimes it stops as abruptly as it starts after 100-300 xruns, but sometimes it just keeps climbing >10k until the audio engine disconnects. This happens even at seemingly reasonable sampling rates (<=48kHz) and buff sizes (256 samps). This is by far the most problematic of the three.
  3. If I configure Ardour to any sampling rate >48kHz or the lower buffer sizes (~<256 samps) I get the out of control xrun issue from above right off the bat. Never a moment of live audio, the xrun counter just shoots up from the start until the audio engine crashes. Nyquist limit discussions aside, this isn't a huge problem since I don't have so great a need to be recording at higher sampling rates. Since the 18i8 is said to go as high as 192kHz I'd like to at least understand what the limiting factor is here though.
If I'm lucky enough that these issues sound familiar, I'd of course love to hear other folks' experiences and solutions. Being under the impression these problems can be as varied as possible hardware and software configurations though, my more realistic hope is to get some direction on how to go about debugging these problems. I've taken a look at latencytop and top as it's being overrun with xruns, but no obvious culprit jumps out. Before I can experiment and take steps to solve these problems I'd love to find a strategy to identify and isolate exactly what's causing them.

GuntherT
Established Member
Posts: 100
Joined: Sun Jun 07, 2015 2:15 am

Re: Debugging Xruns

Post by GuntherT »

Is the xrun situation the same no matter what USB port you use? If so, WiFi is a frequent culprit if the module shares the same IRQ as the USB bus of your ports. If you disable WiFi, do the xruns decrease?

merlyn
Established Member
Posts: 640
Joined: Thu Oct 11, 2018 4:13 pm

Re: Debugging Xruns

Post by merlyn »

Hi alex.

Because you're using a laptop this could be an issue with power management. I'd guess it's an Intel chip. An idea that has come up in other threads is disabling c states like here : viewtopic.php?p=116252#p116252

User avatar
gauderbock
Established Member
Posts: 22
Joined: Thu Oct 04, 2018 1:01 pm
Location: Tirol

Re: Debugging Xruns

Post by gauderbock »

I also have huge bursts of xruns for no apparent reason. It often happens when my laptop is mostly idle, with the xrun count hitting 50k or more over a few minutes while I'm not paying attention. I've not found any cause, but since restarting jack usually fixes things straight away, I'm wondering if it's a problem with jack(2) itself rather than any external influence?

FWIW, AMD Ryzen 3 processor, variety of kernels including Ubuntu low latency and a self-compiled RT, Linux Mint 19.3 running XFCE or Cinnamon, Behringer UCA222 USB sound.

merlyn
Established Member
Posts: 640
Joined: Thu Oct 11, 2018 4:13 pm

Re: Debugging Xruns

Post by merlyn »

@gauderbock I don't think it's a problem with JACK. The common factor in your and @alex's problem is that you're using a laptop. Have you tried configuring c states with a kernel parameter?

I'm using a desktop and I can leave JACK running all day without Xruns.

User avatar
gauderbock
Established Member
Posts: 22
Joined: Thu Oct 04, 2018 1:01 pm
Location: Tirol

Re: Debugging Xruns

Post by gauderbock »

Hmm, I've just tried the c states and CPU temperature was a sustained 75C under virtually no load, compared to the usual mid 40s... That doesn't seem healthy to me so I've backed off for now :D

User avatar
bluebell
Established Member
Posts: 1345
Joined: Sat Sep 15, 2012 11:44 am
Location: Saarland & Frankfurt, Germany

Re: Debugging Xruns

Post by bluebell »

merlyn wrote:
Tue May 19, 2020 11:32 am
@gauderbock I don't think it's a problem with JACK. The common factor in your and @alex's problem is that you're using a laptop. Have you tried configuring c states with a kernel parameter?

I'm using a desktop and I can leave JACK running all day without Xruns.
I am using a laptop, too, and it's stable. I can run it for a week without xruns. At the moment I have an uptime of 10 days.

I use a lowlatency kernel with

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="nohz=off threadirqs audit=0 noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off quiet splash i915.enable_guc=2"
Linux – MOTU UltraLite AVB – Qtractor – https://soundcloud.com/suedwestlicht

alex
Established Member
Posts: 6
Joined: Fri May 08, 2020 5:13 am

Re: Debugging Xruns

Post by alex »

Thanks for all the ideas! Still reading up on c-states and investigating more, but in the meantime:
GuntherT wrote:
Sun May 17, 2020 12:06 am
Is the xrun situation the same no matter what USB port you use?
It's erratic enough that it's hard to tell much marginal difference between USB ports. Out of curiosity, is it generally better to use a port on a bus that the interface won't have to share with other devices? If that's the case, could there be any merit to disabling devices on the bus in question? At first glance, lsusb is showing 11 devices over 3 buses, but many of them are built in, i.e. "Acer Integrated Camera", "fingerprint sensor", "Linux Foundation root hub", etc. Then again, when I connect devices to all 3 USB ports on the machine, all 3 devices appear on bus 2...
GuntherT wrote:
Sun May 17, 2020 12:06 am
If so, WiFi is a frequent culprit if the module shares the same IRQ as the USB bus of your ports. If you disable WiFi, do the xruns decrease?
Disabling WiFi caused a definite improvement (is there an even more thorough way than #/etc/init.d/network-manager stop?). Too bad but I can live without it. While nixing WiFi decreased the frequency and severity of the xrun bursts, I'm still getting some. In addition to WiFi and Bluetooth, are there other usual suspects for services / daemons that are safe to disable and might help? Or a way to identify problematic candidates?


merlyn wrote:
Sun May 17, 2020 11:27 am
Hi alex.

Because you're using a laptop this could be an issue with power management. I'd guess it's an Intel chip. An idea that has come up in other threads is disabling c states like here : viewtopic.php?p=116252#p116252
Reading up on this a bit more. Off the bat though, can preventing the cpu from idling have negative consequences?


On a new note, I can now get Ardour running on 96kHz without the immediate flood of xruns. But it starts with the error:
[ERROR]: AlsaBackend::connect: Invalid Destination port: (ardour:default)
and I correspondingly lose all my hardware outputs, which maybe just precludes xruns in the first place though.

Post Reply