Looking for any Pipewire / pipewire-jack troubleshooting guide

Installation & Configuration Linux
#61

I agree that this is a noble goal, but achieving it often requires compromises. It is essential to evaluate whether these compromises are compatible with the desired outcomes—in my case, the lowest possible latency with zero XRUNs.

When I first started exploring digital recording as a hobby back in 2009, there were (to my knowledge) no Linux distributions dedicated to this purpose. I set up a machine equipped with a Delta 1010LT PCI card running FC10, added the PlanetCCRMA repositories, and followed the instructions. The resulting workstation performed exceptionally well in terms of latency—so well, in fact, that I was able to use it as a remote-controlled mixer for my band. I even created a website for this project, which I called DAMA (“Digital Audio Mixer Appliance”)—years before Behringer began selling their own “stage mixers,” which essentially perform the same function.

Today, hardware is far more powerful than it was 17 years ago, and there are dedicated distributions—such as Ubuntu Studio, Fedora Jam, and AV Linux—tailored for audio and multimedia production. One would expect these to work almost flawlessly “out of the box,” yet they perform worse than my 2009-era FC10+PlanetCCRMA setup. I find this frustrating.

At this point, I refuse to believe that the underlying infrastructure is the problem. The issue likely lies in the configuration of the software stack—PipeWire and WirePlumber (alongside ALSA and, presumably, PulseAudio)—and the effective use of tools like Pavucontrol, various patching utilities, and so on, to achieve a low-latency audio system.

Perhaps what is needed is documentation specifically focused on the intended use case for the installed system—which, in reality, is capable of handling a vast array of tasks. In my case, the goal is low latency with zero XRUNs—specifically, 128 frames at 48 kHz without any XRUNs (which, all things considered, I believe is a modest requirement).

If a precise guide existed for achieving this target (or similar goals within the audio/video realm), I would be quite satisfied.
That is why I titled this post “Looking for any Pipewire / pipewire-jack troubleshooting guide.”

Regards,
MarcoC

1 Like
#62

Before blaming Pipewire for latency and Xrun issues, I would test directly using ALSA.

In my experience, these sort of issues tend to be a symptom of the hardware, drivers, and OS setup in general. Often things like moving the audio interface to a different USB port can make a big difference.

If your setup doesn’t work well with ALSA, then nothing else will, as everything else sits on top of ALSA and depends on it; if you can’t get low-latency directly using ALSA then you are never going to get it using Pipewire or Jack.

Cheers,

Keith

#63

I covered this topic in a previous post:

As I mentioned in that earlier post, I’ve tested my system by configuring Ardour to use ALSA directly, and it works perfectly—much like how my system performed well using JACKD before the arrival/adoption of Pipewire.

What you say is correct; I have indeed observed these differences on my own system, and I’ve made sure to avoid using USB ports that tend to cause issues.

The only downside is that, by using ALSA, I can’t simultaneously connect other “external” sound generators (such as Hydrogen). That said, given the plugins currently available and the ease with which one can compose MIDI tracks, I realize that for my own purposes, I could actually do without those connections and use ALSA.

Regards
MarcoC

#64

The question is, have you tried ALSA directly with the other installations you have tried?

Just because you got it working well on, say, an installation of Debian, does not mean it’s working well with Mint or AVLinux.

Cheers,

Keith

#65

@Majik

I’ve tried to use ALSA in every installation where I’ve found problems with Pipewire, and with ALSA all works fine.

Regards
MarcoC

1 Like
#66

@mcannavo

When reading your response to my little bit of thoughts … You invested a lot of energy with zero results. Distros like Ubuntu Studio did not work.

I think that could be the problem. As an example. I had some problem with my Linux machine. Days after days I communicated with the distro’s forum. The people were very helpful but with no result.

It certainly looked like a SW problem. Then some a though came up : it could be hardware. And so it was a faulty ssd in a raid 1 environment.

So my suggestion is , use a dedicated machine, do new clean install of the operating system. Install all the recommended SW for Ardour only nothing else. With pipewire you still can install and use QjackCTL.

Make sure that Sample rate, Frames per period and periods/buffer are set to the same values in Ardour, Qjackctl and pipewire (where required). Connect your UCMXXX. Make sure that your system gets the update from the right repositories.

Then you should be in business

Good luck and best regards

1 Like
#67

@hase

It is indeed possible that some minor changes to my main laptop system are the cause…

I’ve managed to get hold of a Fujitsu laptop with an Intel i7 and, as soon as I have some time, I’ll run some tests to see if the behavior differs between the two laptops.
Since I use external hard drives to install music-focused distributions, I can boot these distributions on the Fujitsu and check whether there are any differences in behavior compared to my main laptop.

Thanks again to everyone for your patience and support.

Regards
MarcoC

#68

You can install it but it would be rather silly, you cannot change pipewire settings from qjackctl.

#69

You could still use QJackctl for connections. But there’s better solutions for this, such as Helvum or qpwgraph.

Cheers,

Keith

#70

I used qjackctl with pipewire-jack for a while for JACK connections for a long time. It’s a JACK compatible server. I think Ardour doesn’t do anything Pipewire specific, but similar to qjackctl, it interfaces with pipewire-jack due to its compatibility.

#71

So,
an update:

I’ve been running some tests with Ubuntu Studio 26.04 on my “new” dedicated laptop.
Using a buffer size of 128 samples at 48 kHz—configured via the “pw-settings” graphical tool—and incorporating the various suggestions you provided (specifically, setting the “Audio-Pro” profile for the Behringer UMC202HD USB interface through the “System Settings - Sound” panel in the Plasma GUI), I’ve found the results to be acceptable. I only encounter a few XRUNs when configuring output routing or performing tasks outside of Ardour; during normal operation, there are few to none.
If I connect Ardour directly to ALSA, the XRUNs disappear entirely.

One strange behavior I’ve noticed is that, upon every reboot, the output level on my Behringer interface resets to 40%—even though I had set it to 100% via alsamixer and saved the configuration using sudo alsactl store. Adjusting the output levels to 100% through the GUI didn’t help either; they would still revert to 40% after a reboot. Consequently, I turned to an AI (sigh!), which—after offering a series of incorrect or nonsensical suggestions—helped me create a startup script to set the level when the desktop environment loads. That did the trick.

The explanation provided by the AI ​​is as follows:

You are completely right, and I apologize for missing the core of the problem.
What is happening to your Behringer UMC202HD is a known hardware/driver quirk specific to certain USB audio interfaces on Linux.
The interface maps its controls to two completely separate layers:

  1. The Software Layer (PipeWire/wpctl): This is at 1.00 (100%), meaning PipeWire is sending a full, unattenuated digital signal to the USB driver.
  2. The Hardware Driver Control (ALSA Kernel Mixer): Inside the Linux kernel’s USB-audio driver, there is a hidden internal hardware gain or “PCM” mixer element specifically for the Behringer chip. On every boot, the Linux kernel initializes this internal hardware element at a low default level (often around 40%), throttling the audio before it even exits the physical ports.
    Because PipeWire thinks it’s already outputting at 100%, it doesn’t touch or “fix” this hidden hardware ALSA slider during startup.
    Since you must use alsamixer to crank up this internal hardware slider, you can force Ubuntu Studio to automatically apply your preferred ALSA hardware levels right after you log in using a targeted script.

Following this suggestion, I managed to resolve the issue—though I believe PipeWire could (and should) handle such cases or exceptions better, or perhaps avoid interfering with settings configured at a lower level, such as within ALSA.

Unfortunately, I haven’t been able to get Ubuntu Studio running on my primary laptop—which has an internal drive containing Windows 11 (for work purposes)—so I can’t make a direct comparison between systems.

That’s all. Apologies for the length of this message.

Regards
MarcoC

#72

On every boot, the Linux kernel initializes this internal hardware element at a low default level (often around 40%), throttling the audio before it even exits the physical ports.

Adjust the hardware mixer to your preferred level. Run sudo alsactl store

You should get that settting after every boot after that (because ALSA arranges to run alsactl restore during startup)

1 Like
#73

I had the same problems with ALSA levels at 41% on my UMC202HD (Debian 12, jack2d alongside Pipewire). Like you, I had to resort to AI, which, after hours, ended with a script I need to run at startup: amixer -c U192k sset 'UMC202HD 192k Output' 127

(sudo alsactl store didn’t solve it.)

1 Like
#74

And I got a bunch of apologies, as well. Annoying, but just part of the process, I guess.

1 Like
#75

@paul

Paul,

That is exactly what I did—and what I have always done for every Linux installation intended for audio use—but it seems that installing PipeWire (or its auxiliary programs) interferes with the alsactl restore command.

I also checked the setup file at /var/lib/alsa/asound.state, and the levels are set to 100%. Despite this, every time I restart, the levels revert to around 40%.

I eventually had to give in and use the solution provided by the AI, creating a script based on its instructions and configure it as a “Login Script” in Autostart setup :

mkdir -p ~/Scripts && echo -e '#!/bin/bash\nsleep 5\namixer -c 1 sset "UMC202HD 192k Output" 100%' > ~/Scripts/fix_behringer.sh && chmod +x ~/Scripts/fix_behringer.sh

Furthermore, the AI suggestion states:

“The sleep 5 safety buffer guarantees that the script waits for the USB system and desktop to completely load before forcefully snapping the hardware mixer to 100% capacity.”

It works, but it’s not exactly an elegant solution…

Regards
MarcoC

#76

@Largos

…please let us know which applications show and let change piprwire settings

thanks

#77

pw-metadata can help you set the sample rate and buffer size.

First, run: “pw-metadata -n settings” from the command line. In my case, the output is this:

Found "settings" metadata 32
update: id:0 key:'log.level' value:'2' type:''
update: id:0 key:'clock.rate' value:'48000' type:''
update: id:0 key:'clock.allowed-rates' value:'[ 48000 ]' type:''
update: id:0 key:'clock.quantum' value:'1024' type:''
update: id:0 key:'clock.min-quantum' value:'32' type:''
update: id:0 key:'clock.max-quantum' value:'2048' type:''
update: id:0 key:'clock.force-quantum' value:'0' type:''
update: id:0 key:'clock.force-rate' value:'0' type:''

The interesting lines for reading the default settings are the ones with 'clock.rate' value:'48000' and 'clock.quantum' value:'1024'

The other interesting lines are where you find: 'clock.force-quantum' value:'0' and 'clock.force-rate' value:'0' type:''. Of course, they just had to rename the term buffer size to quantum, adding to the mess.

When the values are zero, as shown above, PipeWire uses the default settings, and you can change them to new settings, for example:

pw-metadata -n settings 0 clock.force-rate 44100
pw-metadata -n settings 0 clock.force-quantum 256

Then run pw-metadata -n settings again to see how it works.

The idea behind PipeWire is good, but only for casual users and perhaps users who have a dedicated audio distro, IMO. If the goal is to make sound configuration just work, you need a single GUI tool that can configure everything and do the work; then you have something that just works. I found it much harder to configure PipeWire from scratch than the old ALSA, Pulse, and JACK system. In the beginning, audio could come from the screen monitor’s loudspeakers via HDMI while I was working, anything from a ping from an app to whatever that was non-JACK.

Now JACK is taking control of all sound again when it runs, just as before, and I have peace of mind. I’m sure that it’s very easy for many people to configure this right, but for me it was no easy walk in the park.

#78

A script to change quantum: Loading...

Instructions to change sample rate: Loading...

These provide set to forget solutions that don’t require to load an application.

This more than replaces qjackctl GitHub - magillos/Cable: PyQT application to dynamically modify Pipewire and Wireplumber settings at runtime. · GitHub

There is also qpwgraph, available from pretty much every repo. Made by qjackctl author to replace the connections graph.

1 Like
#79

Just an update about this:

I encountered this same behavior, previously observed in Ubuntu Studio, in Fedora Jam as well.

Since both distributions share the KDE Plasma desktop, it is likely that this behavior is, in some way, caused by the “Sound” panel within the Plasma GUI’s “System Settings” tool.

Regards
MarcoC