Xrun keep coming when using VSTs

#1

Hi there,

I’m using ardour on AVLinux, cat /etc/*version

output:

AV_Linux_MX_Edition-21.3_ahs_x64 Consciousness January 25, 2023
11.7
AV_Linux_MX_Edition-21.3_ahs_x64 Consciousness January 25, 2023

I’m using Liquorix kernel, which should have some realtime-kernel feature (preempt), sudo uname -a output:

Linux elaudio 6.0.0-10.1-liquorix-amd64 #1 ZEN SMP PREEMPT_DYNAMIC liquorix 6.0-6~mx21+1 (2022-11-30) x86_64 GNU/Linux

My USB Audio Interface is M-AUDIO MTrack II Plus.

I’m running Jack with following settings:

Sample Rate: 44100
Frames/Period: 128
Periods/Buffer: 3

I’m having issues trying to play/record in Ardour using the free VSTs used in this guide. I tried to record a track with this setup and I noticed QjackCtl showed a lot of xruns (something in the order or 20 or more…), furthermore after some time recording/playing/having Ardour opened (with connections made) with a Track which includes these VSTs, the O.S. systematically freezes completely, stopping me from doing anything and forcing me to reboot using the power button, which I find really weird… Is there a simple explanation to this freeze?
Looking at the message tab of QjackCtl I can see the xruns come in the form of:

JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
01:00:02.906 XRUN callback (1).

or

JackEngine::XRun: client = ardour was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
01:00:03.739 XRUN callback (1 omitidos).

with the numbers inside the round brackets being incremental.

My PC specs should be ok since I’m working with 32Gb of RAM and an Intel i7 13th Gen CPU.

I think my issue could be similar to the problem described in this topic, where the user was having xruns due to other device/s accessing and holding the bus for a long time, avoiding the USB interface to deliver/receive audio. I tried to follow the topic, but unfortunately I wasn’t able to implement your advices… I issued the lsusb -t command to get some information about my USB devices and buses, here’s the output:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 20000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
    |__ Port 1: Dev 2, If 3, Class=Application Specific Interface, Driver=, 480M
    |__ Port 1: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 2, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 1: Dev 2, If 0, Class=Audio, Driver=snd-usb-audio, 480M
    |__ Port 8: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 9: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 9: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 10: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 10: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

As you can see, all my USB devices unfortunately share the same bus… You can also see I’m using two audio interfaces: one is the M-AUDIO M-Track (Dev 2) and the other is a MIO iConnectivity MIDI to USB interface (Dev 4) I use to drive plugins playing soundfonts and instruments.
I also already tried to connect my USB M-AUDIO interface to all my USB ports and it always appears connected on the same bus (Bus 01).

I also issued egrep hc[di] /proc/interrupts to try to spot USB devices which are sharing IRQs and I got the following output:

 124:          0          0          0          0          0          0          0          0          0          0   12349172          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI 327680-edge      xhci_hcd
 127:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI 376832-edge      ahci[0000:00:17.0]

But I really don’t know how to interpret and cross-reference the data…

I understood devices use IRQs to issue an interrupt and requesting immediate action from the CPU to their data, also if multiple devices share the same bus, one device has to wait the other one has finished with the bus before the CPU can handle its request, I also understood you can assign priorities to IRQ numbers, but if multiple devices share the same IRQ number and you try to prioritize that IRQ number (to make the audio interface take priority over all other devices on the same bus), this will affect all the devices sharing that IRQ number and not only the audio interface…
Yet still I can’t use this information to get the job done… More specifically:

  1. How am I supposed to cross-reference the data from egrep hc[di] /proc/interrupts command to get the USB devices sharing the same IRQ number? Looking at the output of the command it seems that IRQ 124 is used by xhci_hcd device and IRQ 127 is used by ahci[0000:00:17.0] one, but which devices are these? Are they my audio interfaces? I also see that the two devices use different IRQ numbers, does that mean I can solve the problem prioritizing one IRQ number over all the others?
  2. How can I prioritize an IRQ number over the others? Should I change some configuration in the bios or is there some configuration I can do at O.S. level?

I also tried to download and use a realtime kernel (5.10.0-23-rt-amd64) but I still got xruns; maybe a little bit less, but still in the order of one per 3/10 seconds, I’ve not experienced no O.S. freezing though.
I also don’t have WiFi interface since I’m connected via ethernet, so we can’t assume the problem is the WiFi interface searching for networks and meanwhile holding the bus…

Maybe @x42 or @lenovens could give me an hand with this issue?

Thanks in advance for the help

#2

I don’t think I can offer much help, unfortunately. Hopefully others on this forum can provide some useful advice. I am curious, though, what is the make/model of your PC?

One thing to add, I believe AVLinux has the rtirq script installed by default. Have you changed the order of the soundcard priority? (Typing “sudo nano /etc/default/rtirq” from a terminal brings up its configuration file.) I use a USB interface, so I change the default setting of:

RTIRQ_NAME_LIST=“snd usb i8042”

To this:

RTIRQ_NAME_LIST=“usb”

I notice it makes a difference in reducing xruns. “snd” refers to the PC’s built-in soundcard, “usb” is for USB soundcards, and “i8042” is for FireWire soundcards. Priority is left to right, but since I only need low latency with my USB interface, I deleted out the other two. You could also go with this, and it would prioritize USB over the built-in soundcard:

RTIRQ_NAME_LIST=“usb snd”

P.S. You may need to reboot for the changes to take effect.

#3

Hey @GuntherT thanks for the help!

My PC is an assembled one, motherboard is this one.

I tried to edit /etc/default/rtirq the way you suggested, but nothing… Xruns are still there.
I also noticed they seem to come in a random pattern, so that I’m not really able to establish if I have less xrun than before editing the file… I was just able to see they show in frequency between one per 3 seconds and one per 10/20 seconds, but, again, it seems really random…

I also tried to disconnect all my usb devices (I also disconnected ethernet) except the usb audio interface I use to record from my PC and, strange enough, xruns are still there! I was expecting xrun would disappear with the audio interface as the only device connected through USB, but that’s not the case!

#4

That’s a bummer. I had my fingers crossed that would be an easy fix. I don’t know how to prioritize a particular USB device on a shared internal hub, nor do I know if it is even possible. Something else to consider:

Years ago, I assembled a PC whose built-in USB ports on the motherboard created xruns no matter what port I used. I bought a PCI card that provided 4 USB 2.0 ports (USB3 wasn’t a thing yet) and prioritized that card, and it solved the issue. I don’t remember the steps I took to raise its IRQ. I think I linked to a page from wiki.linuxaudio.org that described how to do it for a FireWire card, and I substituted the variables to account for my hardware. If all else fails and you have a free PCIe slot, you could consider popping in a card that provides additional USB ports. There should be a means to give that card the highest priority independent of the built-in USB ports. If you go that route, I think you could find answers on how to prioritize it either online or with advice from others here or on linuxmusicians.com.

#5

Another assembled computer from my past had a NVIDIA card, and I remember additional measures were needed before it could provide low latency audio without xruns. The nouveau driver was insufficient. I installed NVIDIA’s proprietary driver and had to select “Performance Mode” (or whatever it was called) in the NVIDIA settings app before xruns disappeared. Are you using a dedicated NVIDIA graphics card? If you are using Intel’s GPU, I don’t think it would be causing any issues.

#6

Hi again @GuntherT and thank you very very much for all your very useful insights!
… And indeed my PC mounts an NVIDIA video card! It has an RTX3060, but i thought I shouldn’t be concerned as far as I was only focusing on audio stuff!.. So you think it could be the video card?
I can try to connect my HDMI cable to the integrated intel GPU and repeat the test, you think I could be sure the NVIDIA card gets deactivated and would no longer interfere?

P.S. in case I would go for the PCIe card with additional USB ports, could you suggest me some brand/model for the card?

#7

Given what you have described so far about the nature of the xruns, my best guess is the NVIDIA card is affecting performance. Have you installed NVIDIA’s proprietary driver, or are you using the default driver that AVLinux loads automatically? I assume AVLinux’s default NVIDIA driver is nouveau, the open source variant, which gets you up and running but doesn’t fully optimize the graphics card.

There are two ways to install the proprietary driver, either via Debian’s repositories or directly from NVIDIA. Here are some links to check out.

Installation via Debian repos:
https://wiki.debian.org/NvidiaGraphicsDrivers

Installation via NVIDIA’s site:

If you haven’t done so, my recommendation would be to install the proprietary driver and then poke around in the NVIDIA settings app to see if any changes help. As I mentioned before, there was a “performance mode” or something along those lines that did the trick for me, but it was so long ago I don’t remember the specifics.

I don’t know if merely switching the HMDI cable from the NVIDIA port to the Intel port would be a reliable test, honestly. I think it’s possible that the NVIDIA card still being installed, despite being disconnected from the monitor, could still cause issues. In my opinion, a more reliable troubleshooting technique would be removing the NVIDIA card from the machine and then testing for performance differences using the Intel port.

Regarding the brand/model of a PCIe card that provides additional USB ports, I wouldn’t think it is a critical decision. That type of device seems low-level enough that you probably have a lot of options. That being said, I am partial to ASUS components. Both motherboards of the two assembled PCs I mentioned were ASUS, one of which used an ASUS PCIe WiFi card, and I have also owned two ASUS laptops. All of them were compatible with Linux with no fuss or fiddling, and I have never encountered any hardware failures. The components I am no longer using were still functional when I retired them due to age (i.e. one of the motherboards was 32-bit only, and the hardware was no longer keeping up with software developments).

P.S. I think you will need to switch back to the Liqourix kernel in order to install the proprietary NVIDIA driver. It is my understanding the official driver doesn’t work with a realtime kernel.

#8

Here I am again with some little news.

I tried to install NVIDIA proprietary drivers as @GuntherT suggested (unfortunately I found out I don’t have an integrated GPU, so I couldn’t test if xruns still come with my NVIDIA RTX 3060 disabled…), but - unfortunately - xruns are still there.
I think I can be pretty sure to be using NVIDIA proprietary drivers as - according to this Ask Ubuntu’s question - my output of lspci -nnk | grep -iA2 vga is

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate] [10de:2504] (rev a1) Subsystem: NVIDIA Corporation Device [10de:1522] Kernel driver in use: nvidia

In which I can read the Kernel driver in use: nvidia statement.

Making a lot of tests, however, I saw that xruns were coming even without any input connected to the ardour track… The only way to make them stop was to disable the VSTs.
I then realized xruns might came from the mere VST use, going more in deep, I tried to find out if there was some VST in particular which make xruns pop. Even if disabling epicverb VST seemed to do the trick at first, it turned out it wasn’t. In fact, xruns seems to pop when the signal processing through VSTs becomes “complex”, i.e. using a number of VSTs.
I also noticed that changing some of the VSTs with other plugins (Calf Reverb instead of epicVerb, EQ4Q instead of ReaEq and Delay (by SocaLabs) instead of ReaDelay) made the xruns appear less frequently… Maybe LV2 plugins are less “heavy” than VSTs. Unfortunately, however, I still can’t finish playing a track without xruns.

These tests also lead me to the consideration that the tons of xruns I had at the beginning were due to the fact that within my Ardour project there were multiple tracks with a number of VSTs inside, more specifically I had 5 tracks with an average of 8 VST plugins plus a couple of LV2 plugins per track, I don’t know if this is just too much, but when I created a new Ardour project with only one track (same VST per track as before), xruns were much less; although they were still popping when playing my guitar through the plugins.

To clarify a little bit more, I leave here the plugins chain I have in my track, top to bottom:

  • x42 Instrument Tuner (by Robin Gareus) [LV2]
  • Calf Gate [LV2]
  • TSE 808 v2.0 (By TSE AUDIO) [VST]
  • HyBrit [VST]
  • epicVerb [VST]
  • TPA-1 v1.0.1 x64 (By Ignite Amps) [VST]
  • ReaEQ (ReaPlugs Edition) (By Cockos) [VST]
  • Pouli_LeCab2 (By LePou Plugins) [VST]
  • Classic Chorus (By Kjaerhus Audio) [VST]
  • ReaDelay (ReaPlugs Edition) (By Cockos) [VST]
  • Amplificatore Semplice (by Unknown) [LV2] ← This one’s name is in Italian, I guess in English the name should be “Simple Amplificator”

I also tried to do the “inverse test”, i.e. trying to play throrugh Guitarix Virtual Guitar Amplifier and then trying to record the output in Ardour and I actually got no xruns.

Is all this kinda “normal” and I just have to settle for it?..
It won’t be a problem for me to buy some USB expansion card with PCIe interface like this (I googled for an USB expansion to PCIe card with good Linux compatibility and found this, I hope it is the correct model), and try to prioritize that PCIe card if I knew it would do the trick.

@GuntherT Do you remember how did you manage to prioritize this kind of card? Do you think it would solve my problem?

#9

I do not remember, unfortunately, and I cannot locate the webpage I used. It may no longer exist.

I am not sure if purchasing the PCIe USB card will reduce xruns, and I would hate for you to spend money on something that doesn’t improve the situation. It is a possibility, but there are so many variables here, I wouldn’t bet on it being a sure fix.

I saw you posted on linuxmusicians.com. I think it best at this point to see what advice others can offer. While I believe configuring the rtirq script and installing the NVIDIA driver can only help without screwing anything up, I am reluctant to keep throwing suggestions out there that may cause more problems than they solve.

1 Like
#10

Thank you very very much for your help.
I’m just in a “try and error” situation since I reinstalled AVLinux not so long ago and, thus, I have not so much to lose if anything goes wrong (if something gets screwed up, I’ll reinstall the O.S. …)

Unfortunately, at the end of the day I don’t even know if this behaviour with VSTs is “normal” or “known” or if it’s weird and could be addressed somehow… So I’m really clueless by now :sweat_smile:

#11

Modern kernels can switch preemption models at runtime. This description indicates that is the case for your kernel: PREEMPT_DYNAMIC

On recent kernel versions you can find the mode currently in use with this command:
sudo cat /sys/kernel/debug/sched/preempt

On my system this is the current result:
none (voluntary) full

Which indicates that my currently running kernel is using voluntary preemption, as opposed to no preemption or full preemption (full being the mode which is configured if you use CONFIG_PREEMPT when compiling the kernel).

If you kernel is currently running in “none” or “voluntary” mode you can see if running with full preemption makes a difference with this command:
sudo echo full > /sys/kernel/debug/sched_preempt

Note that may not work during runtime depending on your system ROM settings (i.e. UEFI ROM can lock out changes in some cases; I do not know if that is only the case when using secure boot, or if there are other cases when runtime changes are prevented).
If runtime change is prevented, you can enter the preemption mode desired on the kernel command line (add preempt=full either by stopping the bootloader and editing for a one time test, or editing the bootloader command line and default setting if you want to make permanent).

1 Like
#12

Hi @ccaudle and thank you for the answer!

Unfortunately issuing the command

sudo cat /sys/kernel/debug/sched/preempt

gives me the following error:

cat: /sys/kernel/debug/sched/preempt: No such file or directory

… It seems like I don’t have that file…

Do you have any idea on how to get that information?

#13

I just found that issuing this:

sudo dmesg | grep Preempt

command in my AVLinux (Debian based) I should get the same information, if I got the whole thing right obviously.

My output is:

[    0.037870] Dynamic Preempt: full
[    0.037902] rcu: Preemptible hierarchical RCU implementation.

So I should assume that my kernel is already running full preemtpion; @ccaudle, do you think it’s correct?

#14

The location may be different in different kernel versions. I saw one web page which referenced /sys/kernel/debug/preempt but that location did not exist on my kernel version.

Seems like your kernel runs in full preempt mode already, so that would not be the problem.

#15

Hey, just stumbled on this thread. I used to have lots of xruns as well but since my laptop is quite old and lower spec than your system you shouldn’t have any troubles at all.
I’m using the standard kernel (OpenSUSE TW) which is also preempt_dynamic and only needed a few tweaks, most already metioned here.

The one thing I don’t see mentioned is to set your CPU governor to performance mode.
command = cpupower frequency-set -g performance
Use cpupower frequency-info to see which governors are supported.

If that doesn’t work, you can always try to record with higher sample rates, if buffer size really needs to be that low just for latency ?
I always remember: latency = frames|buffer size / (Sample Rate / 1000) so can play with that ?

Good luck :wink:

#16

I located the webpage I used as a guide to prioritize the PCI card on the old computer I mentioned:

http://subversion.ffado.org/wiki/IrqPriorities

IIRC, I replaced “yenta” in the rtirq config with whatever that card was named after running “cat /proc/interrupts” from a terminal, for example:

RTIRQ_NAME_LIST=“yenta”

1 Like
#17

Hi @BartVaes, thank you for the answer.

Googling for a while I found this command:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

which, If I understood it right, should give me the state of my CPU governor. In my case the output is:

performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance
performance

Can i conclude my CPU governor is already in performance mode?

#18

AV Linux has that enabled by default so yes it will be unless you change it manually…

1 Like
#19

thank you for the clarification @GMaq.

Do you also have some ideas on why these xruns show?

#20

Hi,

In reading over the thread I don’t have an obvious answer, AV Linux is certainly not perfect but I don’t think it is the culprit here in particular… All of the common things to boost performance and all of the things the Realtime Configuration scan in AV Linux indicate are already done out of the box, is this a guarantee across all systems…? Nope… because hardware varies wildly, this is why the rtirq script is left for you to edit based on what actual soundcard you have. In my own example I have a Studio Desktop that flies with AV Linux and a Samsung laptop with Broadcom Wifi that Xruns like a drunken sailor if the WiFi is turned on…exact same OS, wildly different performance… the common-sense AV Linux defaults can’t fix stuff like shared IRQ’s, bad Video drivers or other non-optimal hardware issues and to be clear not every computer is a great Studio computer…

Secondly, It is a common want for people to run Windows VST’s on Linux so I provide the ‘infrastructure’ for it as a convenience but that doesn’t mean there is any guarantee that Plugin chains with native Linux Plugins and Plugin chains with Windows Plugins will perform the same… Yabridge is close to a miracle bridge application but you are going outside of the DAW running a bridge that relies on a complete running compatibility layer to run out of platform binaries… Yes it works but it is only reasonable to expect it may not work as smoothly and as quickly as running native Plugins within the DAW…

AV Linux 21.3 comes with Wine-Staging 6.6 to work with yabridge, if you want to try a newer version of Wine-Staging you can use the MX Package Installer, enable the ‘MX Test’ Repo and install a newer version of Wine-Staging and it’s a longshot but it’s possible it may give better performance than the stock Wine-Staging that came with AV Linux 21.3… :man_shrugging:

Side note:

For AV Linux Users having to do a deep dive into the system Configuration files don’t forget the simple ‘System Editor’ found in the Accessories menu… :wink:

shot-2023-06-28_18-53-51
shot-2023-06-28_18-53-51604×546 88.4 KB

1 Like