Ardour 6: heavy xruns

Good afternoon all,

I’m having trouble with a fresh install of Debian Buster and Ardour 6. I’m getting plenty of xruns (hundreds of them) when moving an Ardour window on my screen. My old, deceased computer with less RAM and a smaller overall performance hardly gave me any. Here’s my setup

Hardware:
Acer Aspire XC 886 Desktop+AMI Bios R01-A1
8 GB RAM
Intel Core i3-9100@3.60 GHz
SATA HDD Seagate Barracuda

OS:
Debian Buster, various kernels with and without RT, stock and Liquorix

Audio interface:
USB Audio device Edirol UA-4FX

jackdrc:
/usr/bin/jackd -S -v -p128 -t1000 -dalsa -r48000 -p64 -n3 -D -Chw:UA4FX -Phw:UA4FX

jackd --version:
jackdmp version 1.9.12 tmpdir /dev/shm protocol 8

My old Setup (Debian 9 on a stock 4GB RAM Lenovo Desktop computer with the same audio interface and Ardour 5.x) gave me an occasional xrun when under heavy load. With my current setup, changing windows alone es enough to create xruns. Grabbing and moving a window literally creates hundreds of them. I have used different kernels (my old system used to run the Liquorix kernel) with no noticeable difference. I have also applied the common tweaks:

limits.conf
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -19

sysctl.conf
fs.inotify.max_user_watches = 524288
vm.swappiness = 10

Running realTimeConfigQuickScan.pl gives me:

Checking if you are root… no - good
Checking filesystem ‘noatime’ parameter… 4.19.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors… CPU 0: ‘performance’ CPU 1: ‘performance’ CPU 2: ‘performance’ CPU 3: ‘performance’ - good
Checking swappiness… 10 - good
Checking for resource-intensive background processes… none found - good
Checking checking sysctl inotify max_user_watches… >= 524288 - good
Checking access to the high precision event timer… readable - good
Checking access to the real-time clock… readable - good
Checking whether you’re in the ‘audio’ group… yes - good
Checking for multiple ‘audio’ groups… no - good
Checking the ability to prioritize processes with chrt… yes - good
Checking kernel support for high resolution timers… found - good
Kernel with Real-Time Preemption… found - good
Checking if kernel system timer is high-resolution… found - good
Checking kernel support for tickless timer… found - good

Am I missing anything here?
Any input would be greatly appreciated.

USB device and <256fpp @ 48kHz (here even 64 / 48k) usually requires a realtime-kernel.

Have you set up rtirq (kernel boot option “threadriqs”, and apt-get install rtirq-init)? That may already help with debian’s stock kernel.

Also try different USB ports and see if you can get the device to a port that has no other devices on the same bus. Check with lsusb -t.

1 Like

If the xruns more or less only appear when you’re moving the windows it could point to the graphics card or the driver. Or possibly some IRQ interaction between your sound and graphics card.

I can’t find it now but unless I remember wrong someone posting here a month or so ago with xrun problems and they went away when he updated the AMD graphics driver

1 Like

I have booted the Debian RT kernel with the “threadirqs” option but sadly it doesn’t seem to make any difference. I have yet to try connecting the audio device to another USB bus (probably need a new cable for it) but in fact I don’t expect much here. Only keyboard and mouse are on the same bus which I believe used to be the case on the old system. Anyway, thanks a lot so far, I was totally unaware of the “threadirqs” option.

I thought the threadirqs option is only needed for low latency kernels, but not for RT kernels.

Does this also affect the Debian non RT kernel?

Did you try a different window manager (e.g. openbox) for testing? Do you use compositing and does it change when you turn it off?

Have you also installed rtirq-init?

The reason to use threadirqs is to allow rtirq to prioritize IRQs (prefer the soundcard, or here USB, over other hardware, e.g. graphics).

You can force-enable it when configuring the kernel. Some PREEMP-RT patched kernels include this option.

1 Like

What is the DSP load when idling with a session open ? In this thread a high DSP load on idle was solved by moving the sound card to usb-c.

An idle session has a DSP load of 9-11%. With guitarix started, it goes up to 16% and with Ardour and a loaded project it normally stays just under 20%. Xruns even occur (rarely, though) with both guitarix and Ardour with a loaded project open, but transport not running (i. e. playing back).

Yes, installed per the standard Debian sources. The version no. is 20150216-2 which appears to be quite old.

I’ve tried other, more frugal window managers like jvm, to no avail. I’ve always used xfwm4, with compositing eyecandy deactivated. I’ll give openbox a try since you mentioned it but I don’t expect a radical change here.

Coming back to the rtirq topic - /etc/init.d/rtitq status gives me

167 FF 85 - 125 2.2 S irq/124-xhci_hc
59 FF 50 - 90 0.0 S irq/9-acpi
82 FF 50 - 90 0.0 S irq/8-rtc0
159 FF 50 - 90 0.0 S irq/16-i801_smb
170 FF 50 - 90 0.0 S irq/126-i915
171 FF 50 - 90 0.0 S irq/123-ahci[00
[…]

which means the USB driver already has a priority over the graphics card. Is that correct?

Yes it is.

It may still be possible that the graphics-card can hog the bus for along time. but with i915 driver that should not be the case.

What does lsusb -t show? Are there other USB devices that could interfere?

$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 11: Dev 6, If 2, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 11: Dev 6, If 0, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 11: Dev 6, If 1, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 14: Dev 7, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 14: Dev 7, If 1, Class=Wireless, Driver=btusb, 12M

Notes: I only use keyboard and mouse, no other USB devices (apart from the audio device of course). I cannot deactivate Bluetooth in the BIOS, but unloading the BT modules makes no difference that I notice. One option would be to move the audio device to Bus02 but I need to get a proper USB-C adapter first. I still doubt there would be a radical change.

My old system had an i945 graphics card running on an i915 driver, and like I said, it performed very well and threw xruns only under high loads.

Now I’m confused. Bought a USB3 hub with USB-C and attached it to the USB-C socket on the front panel.

$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
[…]

Good, that’s what you’d expect. Now I plugged the USB audio device into the hub - and:

$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 7: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 8: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 16, If 1, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 16, If 2, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 16, If 0, Class=Vendor Specific Class, Driver=snd-usb-audio, 12M
|__ Port 14: Dev 7, If 0, Class=Wireless, Driver=, 12M
|__ Port 14: Dev 7, If 1, Class=Wireless, Driver=, 12M

Why does it still show up on Bus 1?

Mouse actions on the desktop seem to be the source of xruns. Namely when moving Ardour windows (I typically have both the editor and mixer window open), xruns appear in hundreds, and the DSP load display on the top right side of the editor window goes up to above 90% and turns red, even when nothing is being played back. Moving the window with playback on heavily distorts the sound.

Since it appears you are using Jack… can you post up the message log when you start Jack? I am curious if it is actually starting in real time mode (I don’t see a -R in your command, and I can’t remember if it runs in real time without that or not)

   Seablade

Sun May 31 02:38:10 2020: Starting jack server…
Sun May 31 02:38:10 2020: JACK server starting in realtime mode with priority 10
Sun May 31 02:38:10 2020: self-connect-mode is “Don’t restrict self connect requests”
Sun May 31 02:38:10 2020: Acquired audio card Audio1
Sun May 31 02:38:10 2020: creating alsa driver … hw:UA4FX|hw:UA4FX|64|3|48000|0|0|nomon|swmeter|-|32bit
Sun May 31 02:38:10 2020: configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 3 periods
Sun May 31 02:38:10 2020: ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format
Sun May 31 02:38:10 2020: ALSA: use 3 periods for capture
Sun May 31 02:38:10 2020: ALSA: final selected sample format for playback: 24bit little-endian in 3bytes format
Sun May 31 02:38:10 2020: ALSA: use 3 periods for playback

I think I remember jackd is running in RT mode by default.

Did you test what happens when period=256 frames?