Systemd and xruns

#1

I am constantly trying to track down xruns I am getting. I have a complete new setup now (dedicated new computer only for recording, running stock Debian “Buster”, and a Juli PCI audio device), and I have followed the usual rules and hints for setting the system up. Before going to serious recording work, I am killing all daemons and unloading all kernel modules not absolutely essential (i. e. network related modules), but I am still getting xruns, even when a project is loaded but transport not running.

Before going into detail, I’d like to know if people here have had problems with the various systemd daemons present on most linux systems, and if Devuan would be worth a try since it runs without systemd.

#2

I can attest to that (although I can’t say that it’s necessarily systemd). At this point, I have scripts which will disable all bluetooth and networking. It used to successfully kill pulse, but they changed something in the past year or so, and it gets started back up eventually. I think perhaps pulse is the last culprit, but haven’t been able to nail it down. At one point, a few years ago, I was seeing a periodic xrun (every, for example, 45 minutes more or less) with nothing running. I was not able to pin it down… every time I would think I would find something, like some xfce-windowing-spawned thing, it would elude me :slight_smile:
All that being said, I have not noticed a discernable problem with the xruns that I’ve had, to my ears. But my ears are not great :slight_smile:
I never went as far as removing modules.

#3

I’m fine with debian/buster on a Thinkpad X250 and debian/bullseye on X1. USB soundcards work reliably (zero xruns) down to 64fpp / 48kHz with debian’s rt-kernel.

For power saving reasons I usually use the default kernel, but with threadirqs (and rtirq-init). There are x-runs when using USB devices with < 256 fpp. but things are usable at 1024.

I don’t see how systemd can get in the way of reliable audio I/O, at least not directly.

#4

… I suggest to try AVLinux (runs live from USB-stick) for a 2nd opinion first.

1 Like
#5

Running Debian Bullseye on the DAW in the studio. AM4 1700 with a PCI HDSP 9632. At 48K /w 128 buffer it’s rock solid. No xruns, none.

Stock system minus the custom RT kernel. Wanted to set the timer to 1000Hz.

#6

Why do you expect this to make any difference?

Neither the soundcard, nor MIDI use the system timer and Ardour’s (or JACK’s) scheduling is soundcard IRQ driven.

#7

It prevents a nonstop string of xruns from occurring after an hour of so of live recording with the Xtouch Compact + Xtouch One connected via USB.

#8

Kubuntu 20.04 with ubuntustudio on top which has systemd. Pulse is bridged to jack though pulse’s udev and alsa modules have been unloaded. Old (these days) i5 4 core with intel graphics, wired network. I was able to run the ffado back end on jack with latency set to 16/2 for a number of days with no xruns. This includes things like youtube videos through pulse to jack, running Ardour, etc. My Delta 66 (like Delta1010 with fewer channels but same ice1712 chip) can also run at 16/2 but not with zero xruns. It is definitely worth making sure the driver’s priority is up top. Also rtirq comes with snd listed but I have found that doing something like snd_ice snd to make sure your Juli is ahead of the internal HDA High-latency Audio Device or The HDA device may affect your Juli.

1 Like
#9

I think I’ve nailed it. My computer has (unlike my old computer) an internal audio device that can’t be disabled from the BIOS. The original setting in /etc/default/rtirq

RTIRQ_NAME_LIST=“snd usb i8042”

gave both audio devices the same priority. Apparently

RTIRQ_NAME_LIST=“snd_ice1724 usb i8042”

did the trick. “snd_ice1724” now has the top priority of 90, with the rest following from 85 down. The system is running stable now.

Thanks to all who contributed, and especially to Len who nudged me into the right direction.

1 Like
#10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.