Since Linux Distributions have migrated from Jack to Pipewire, I’m not able to get a recording session free from XRUNS anymore.
I’m using the same Laptop (HP AMD Ryzen 7) and the same external USB interface (Behringer UMC202HD) to perform recordings in Ardour, and all was good until native Jack was installed in Linux distros. But since Pipewire has been used by any (ALL) of the distros I used before, I’m not able to get acceptable recording quality in terms of XRUN glitches.
I’ve tried Ubuntu Studio, Linux Mint, Debian, and now trying AV Linux MX 25 (that seems to behave a little better) with realtime kernels, performing any kind of optimization specified in the rtcqs script, tried to disable Wi-Fi, etc. but I can’t get any acceptable result anymore, even if specifying 256 / 512 frames al 48Khz sampling rate …
I’m aware that this is NOT an Ardour problem, but I’m trying here, in this forum, because probably other people got into similar troubles.
Can anyone please give me some advice for any tutorial or documentation specific to Pipewire / Pipewire-Jack that can help me to identify and solve the problems?
You might know that thread already. Also i can’t say if it is good or will help, i only know it does exist. (a quick search for “xruns” in the first post of that thread doesn’t seem to have many tips, but i only glanced).
Good luck.
Hello !
Well, I’ve tried following so many tutorials, but I didn’t know this one so I’ll try it, even if I don’t use Fedora Core anymore (buy maybe I will install Fedora just to give it a try).
The 256/512 frame values you’re using are pretty conservative. You shouldn’t need any sophisticated tweaking to achieve decent performance on modern hardware.
If you’ve run rtcqs and the report looks good, there really isn’t much more to do.
Just make sure your user belongs to the audio and pipewire groups (or their equivalents in your distro) and that you’re using the Pro Audio profile for your Pipewire sound device. This is important and often overlooked.
It may also be worth checking the ALSA backend. If you see a substantial performance improvement with ALSA, that would point to a bottleneck in your Pipewire configuration.
Yes, You’re right: 256/512 values lead to an unacceptable (im my opinion) latency/delay when recording Vocal or Instruments while monitoring the sound; in fact, before Pipewire (using native Jack) I’ve always used a value frame of 64 (at maximum 128) without getting into xrun troubles. But using Pipewire, with the same equipment/hardware configuration, I get xruns even increasing values to 256/512 !!!
The user groups are Ok, but I will check your advice of having a Pro Audio Profile for the sound device: in fact, it’s the first time that I read anything about “Pro Audio Profile” existence, and I don’t know anything, so I need to find information about it.
If you want to understand what it actually does, you can find some technical information here:
Edit: it’s not mentioned in the link above, but I’m pretty sure the Pro Audio profile also enables IRQ-based scheduling, which directly affects latency/performance.
Running stock Debian 12 and 13, I’m still using jack2. Have you considered returning to it? (I was a little confused when you said “all was good until native jack was installled.”) I believe the only downside to running jack alongside pipewire is that I have to do a bit of fiddling from time to time to route desktop audio.
I will say, though, that 256 is the lowest buffer I can run without xruns.
I ran the liquorix kernel for a few years, but I reverted back to the stock kernel after testing the two side by side. (I detected no advantage to to the alt kernel.)
Yes, the interface has hardware monitoring feature but, in the past, with Jackd2 daemon and QJackctl (in the “pre-Pipewire era”) using it, for me, was just an option: I wasn’t obliged to do it in order to record live stuff like guitar or voice in a comfortable way.
Thanks a lot for your advice. Yesterday i tried to do it (AV Linux 25 Mx Edition) but I didn’t have any benefit from it. I will study the technical link and try again.
When I say “all was good until native jack was installled” I’m talking about using just JACKD2 daemon, and not the Pipewire+pw-jack combination. I don’t understand the reason behind this change to Pipewire, adopted by all Linux distros, since it has effectively worsened the system’s performance and ease of use.
Before Pipewire, with my hardware, I was able to record live instruments using 64 value without xruns.
With my hardware configuration, using liquorix kernel led to a tangible performance improvement.
Last time i checked it was possible to run jack2 instead of pipewire on debian-based distributions.
I am not too much into the details, so it is either stop it and wireplumber from starting (i assume but am not sure on debian systemd is involved) or remove it completely. Distros seem to start it differently.
(You might first want to check what depends on it, adding -s like --simulate for the apt remove command will show you if it will take away half of your system, or anything you don’t want removed).
I have a devuan (debian without system) respin on sourceforge, and it has audio tools and it uses jack2. But it probably is not well done, and i can’t promise anything (not even that it boots). Don’t use it (sonic-linux). Just do it yourself.
Best might be to ask at the MX Forum how to do it in AV Linux.
As said, i did it half a year ago, so things might have changed. Just some general thoughts, no advice. Take care, good luck.
What you want to do is run jackd instead of the pipewire-jack module. You do not need to replace the entire pipewire server, you should keep core pipewire and the pipewire-pulseaudio module, but remove pipewire-jack. When jackd starts it will request exclusive access to the ALSA driver and pipewire will gracefully hand off to jackd.
There is a jack client module available for pipewire if you want to be able to route desktop audio through jackd.
Most of the tips for better pipewire performance should be taken care of in AV Linux. I think the big ones would be making sure your user account can use realtime scheduling (shown in the output of ulimit -r), using the pro audio profile for the audio device, and making sure the CPU is not switching clock speeds while running (use either the performance governor, or user mode governor and manually set a fixed clock rate if the performance governor generates more heat than you want).
One thing to also check is that the recommendations for group membership have changed over the years. The 99-cpu-dma-latency.rules from Ardour uses “audio” as the group name, but depending on when and how your system was setup it may use “audio,” or “jackuser,” or “pipewire” as the group name intended to be used for users needing realtime permissions for audio scheduling. So as an example if you use the Ardour udev rules file directly, but your user is only a member of a group named jackuser, and not a group named audio, the rules file will not have the intended result.
I don’t know if he wants it that way or not (i for one sure have no need for pipewire).
To me it sounded as if he would prefer to just go back to jack, which had no problems.
If it is as simple as removing pipewire-jack and starting jack2 with qjackctl or cadence, then even better, and worth a quick test if it solves the problems.
Depending desktop use, removing Pipewire may require replacing it with Pulseaudio.
Jack/Jack2 is not a desktop sound server. If you remove Pipewire and replace it with Jack2, that will work fine for Ardour and other Jack apps, but it won’t work for most web browsers, media players, and other applications.
That might be fine for you, but it probably won’t work for a lot of people.
Part of the reasoning behind Pipewire is that having different sound-servers for desktop use and for pro-audio use was clunky and confusing (although various community hacks and developments eventually managed to make them work pretty well together). The idea behind Pipewire was to have a single sub-system which did pro-audio and desktop audio (as well as video) seamlessly, more like how it works on Apple Macs.
I’m not saying it’s done that. In fact, I would argue, it’s caused a lot of confusion (especially with old-hands who have learned, and rely on, the old Pulesaudio/Jack way of working with bridges, etc.).
Man thank you for bringing this up and thanks to all the contributors in this thread for their suggestions! I’ve been having the same trouble ever since I switched from Debian 11 to Debian 13, it’s been quite annoying.
Now I have a few tools to look into the issue, what a relief. Particularly the instructions in the “WirePlumber Pro Audio Profile Explained” follow-up article about pw-top appear to be most useful.
Yes, I know and tried to do this and this surely works, but my point is: why change from something that worked almost out of the box (JACKD2) to something that is a nightmare to configre and use (Pipewire + pw-jack), justo to be obliged to uninstall it and return to the old way?
Keith, I used Jack and Qjackctl and was able to use it for “pro-audio” as well as “amateur”, playing with QJackCtl configuration/routing. It was not so difficult and, in fact, it worked well.
I want to illustrate my point with a real-life example: a few years ago, a friend of mine—the keyboardist in the band we played in—used to make semi-professional audio recordings on Windows using Cubase. Since the Cubase license was extremely expensive, he used a cracked version of the program; after a few weeks, it would stop working, forcing him to find and download a new (cracked) version.
I showed him that by using Linux, Jackd2, QJackCtl, and Ardour, I could do the same things legally—using Open Source software—and do so easily, “almost out of the box.” At the time, we used Jackd2 to connect Hydrogen and other external sound generators (I don’t recall their names) to Ardour. It worked perfectly, with very low latency and no glitches or xruns.
Today, however—with the advent of PipeWire and the myriad auxiliary tools and programs created solely to make it work decently (pavucontrol, wireplumber, Cable, Cables, etc.)—that same friend would almost certainly go back to using cracked software.
It doesn’t seem like a positive development to have released a mountain of software that is incredibly difficult to configure, use, and get running smoothly, all to replace something that worked well right out of the box. It only serves to reinforce the idea that Linux and Open Source software are things for nerds.
But maybe I’m just getting too old to understand the benefits of “progress”
linuxdj.com looks like AI generated content, even the title of the link is already a rule of three. I’d take anything put on there with a grain of salt, you might want to check their downloads for instance, they’re empty tarballs. This site is also not affiliated with linuxaudio.org in any way.
At least “cpupower frequency-set -g performance” works, but it doesn’t seem to be much of a remedy, the xruns persist.
I’m running Ardour 9.8, optimized version, from the nightlies. The system is Debian Trixie on a Lenovo ThinkStation S30, 3,7GHz Quadcore Hyperthreading CPU, 16GB memory, and a 450GB SSD. The video card has 2 GB memory.
Next thing I’ll try is the plugin DSP load as Robin suggested. In the meantime, anyone any other idea where to look or what to do? Particularly about pw-top and pavucontrol? I’d be much obliged.
Another question: What does the number in brackets following “DSP %” in the upper right corner of the GUI mean? I always wondered.
(sonic-linux). Just do it yourself.
