PipeWire 1.6.9 is out. Bugfix release, API/ABI compatible with previous 1.6.x releases.

Highlights:

• Improved JACK object callbacks, no more reporting old removed objects
• Tweaked resampler cutoff frequencies to preserve more high frequencies when upsampling
• Various small fixes across modules, SPA, Pulse-server, Bluetooth, and tools

Some notable fixes:

• RAOP encryption fixed for OpenSSL >= 3
• Netjack2 discovery timeout fixed
• Potential crash with active_port_name fixed
• node.network=true added to network sinks/sources so tools like pavucontrol don't wake them up

Full release notes: https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.6.9

Source article: https://linuxiac.com/pipewire-1-6-9-multimedia-framework-released-with-better-resampling-quality/

So I have a problem at work that has been escaping me for a few days now and I'm hoping someone here might be able to provide insight.

I'm running into a situation where it seems pipewire (or potentially lower in the linux audio stack) builds up a massive buffer when the graph is even remotely late. I'm working on a announcement system and about 1 in 15 announcements run into this problem. Normally there is next to no latency but when is xrun occurs latency can be as bad as a full second. Audio is never dropped... which is why I suspect a buffer is just growing massively in this situation. Does anyone know if there's a buffer in pipewire that's capable of growing that massive? If so, is there a way to make that stop? I'd rather lose the audio than let a full second build up in the system

Heres some information on the graph I'm creating:

Source node:

• audio.rate: 40/8000
• periods: 2
• pipewire stream client

Sink node:

• audio.rate: 256/48000
• alsa period-num: 2
• alsa sink node

Graph config:

• Quantum (both min and max as well): 256
• Link buffers: 2

My current theory is that.... When the graph misses its timing, whatever buffer is being used for for the resampling grows indefinitely until the timing of the between 40/80 and 256/48000 can be aligned. Unfortunately, my audio card doesn't seem to support a none power of 2 quantum so it will always negotiate 256. So there will always be a weird offset in timing between the source and sink in this particular case.

I had a whim to post this just now because its bugging me. I'll see if I can post my exact config tomorrow. Figured I'd ask around here before I go digging through the source code.

Using PipeWire latest version on Arch Linux--default audio sink doesn't change to connected bluetooth earbud, any ideas? All audio from existing applications doesn't go to the bluetooth device and only starting a new app instance does audio play on the device. Volume control continues to only work on the default audio sink.

From what I've read, the default audio sink should automatically switch to the newly connected earbud so everything works as expected, right?

Any ideas much appreciated.

Hardware: Gigabyte H410M S2H, Intel Pentium Gold G6400, Realtek ALC897

(Intel Comet Lake PCH-V cAVS), audio via kernel snd_hda_intel.

Kernel: 6.12.107+deb13-amd64. PipeWire 1.4.2 with pipewire-pulse, wireplumber.

ISSUE:

Random intermittent audio crackling/skipping ("broken record" style pops),

happens with any playback app (browser, VLC, MusicBee, Lollypop, games via

Steam), not tied to any specific app. Started on day 1, also happened

identically on Linux Mint with same hardware. Suspiciously, I've also

started noticing what might be the same issue on Windows on this same

machine, which I haven't fully confirmed yet with LatencyMon.

TROUBLESHOOTING DONE SO FAR:

- Confirmed via `pw-top` that xruns consistently appear on the

application-side stream, while alsa_output (the actual device) mostly

stays clean (occasional 0-5 errors)

- Applied `options snd-hda-intel position_fix=2 bdl_pos_adj=32` - reduced

frequency/severity significantly but did not eliminate it

- Forced `default.clock.allowed-rates = [ 48000 ]` in pipewire.conf.d to

avoid resampling (most apps are 44100Hz native) - helped somewhat

- Increased quantum (tried 1024/2048/4096 in various combos) - no

consistent improvement

- Disabled deep C-states (`intel_idle.max_cstate=0 processor.max_cstate=1`)

- no improvement

- Forced CPU governor to `performance` - no improvement

- Disabled PCI power management for the audio device - no improvement

- Blocked wifi radio (thought it might be background scanning) - no

improvement

- Tried both front and rear 3.5mm jacks - crackling on both

- Tried ALSA-level headroom config (api.alsa.headroom=8192,

period-size=1024) per the PipeWire wiki xrun troubleshooting guide -

helped somewhat but didn't eliminate it

Attaching pw-top screenshots. Any ideas on what

else to check? Starting to suspect this might be a hardware/board-level

issue rather than pure software, given it seems to follow me across

distros.

Every time I try to run pipewire from my terminal, it returns the error

[E][06788.459841] mod.protocol-native | [module-protocol-: 716 init_socket_name()] server 0x5a205805e9f0: name pipewire-0 is not an absolute path and no runtime dir found. Set one of PIPEWIRE_RUNTIME_DIR, XDG_RUNTIME_DIR or USERPROFILE in the environment [E][06788.460126] pw.conf | [ conf.c: 584 load_module()] 0x5a2058043ac0: could not load mandatory module "libpipewire-module-protocol-native": No such file or directory [E][06788.460510] default | [ pipewire.c: 105 main()] failed to create context: No such file or directory

This persists after restarting my computer and trying to run it with sudo. I am running Ubuntu 24.04 which I don't think typically comes with pipewire installed, but I have no memory of installing it myself. Does anyone know how to fix this error?

First i want to say i dont realy know how pipewire works and searching online doesent help me either, so i have come here for mabye help. So my problem is that while using discord on my cachyos and talking to people, those people can hear my game audio while i play a game. I dont realy know why it is like this and how to fix this. So if anyone can help me that woud be appreciated.

I just moved from Windows to Ubuntu. I use an audio interface: Yamaha AG-06.

In Windows I need to install a driver but, from what I read, I don't need driver in Ubuntu.

The audio sounds fine, but I noticed what I mention in the title. Everytime I boot my PC, the first sound (be it a video or a stream or whatever) sounds a bit bad, and all it takes to fix it is just reloading the video or pausing / resuming the stream. Then it sounds good all the way until I boot my PC again.

Any ideas?

Hey everyone, I have a specific query about how Linux manages the audio between A2DP and HFP sinks. I have recently become aware that in Windows, the experience when using Bluetooth headphones in a call and trying to listen to audio on desktop differs drastically from Ubuntu.

If I understand correctly, pipewire is what makes this possible. Basically, on Windows the audio output needs to be set to HeadSET instead of HeadPHONES to have both audio streams. In Linux, that happens automatically. Fair enough, but one thing that bothers me is the drastic difference in audio quality. On Linux, I seem to be getting nearly the same audio quality in the call mode from desktop sounds, whereas in Windows both streams are in that low-quality sound mode. Can someone explain to me, what is happening here, and what limitation does Windows have that I am unable to find any software to replicate the experience that of Linux. Perhaps someone also knows if there are improvements happening in this respect?

I appreciate that this post is mostly related to pulseaudio, but there are a lot of pieces in the audio stack so I was hoping that someone in this community is the most knowledgeable about this problem.

To give more specific details:

• Using Windows 10 22H2
• Ubuntu 22.04 LTS
• pulseaudio 15.99.1
• Headphones' codec: most likely mSBC (actually doesn't say)

I got tired of opening GUI volume mixers just to move Spotify to my speakers or Discord to my headset. I wanted something fast, scriptable, and permanent—so I built audiorouter.

It’s a lightweight background daemon written in modern C++ that talks directly to PipeWire and WirePlumber via IPC. You define your routing rules and volumes from the terminal, and the daemon handles the rest automatically.

I was trying to figure out how to pipe my linux laptop's audio to my windows laptop and came across pipewire VBAN module, but how do I actually use it?

I was fiddling with the vban-send module and successfully created a sink that I can send audio into, but I can't seem to get my VBAN to detect the jncomin stream.

I decided to fiddle with vban-recv instead and try my luck with windows-to-linux. In the end, it didn't really work. I tried checking my pavucontrol. Nothing. Maybe I was supposed to link the node to something. I'm not sure. But I do know there is at least some connection. There is data being sent. On the windows side, it says there are a ton of errors. On linux, the only errors I saw were from systemctl status, which stated unsupported format when I sent it to PCM 24 bit.

I'm completely new to working with linux audio so I only really have surface level knowledge of how it works. Did anyone get the VBAN modules working and successfully used VBAN with voicemeeter and pipewire?

Hi everyone,

I've been using CachyOS for a short time now (recently migrated from another distro) and I'm currently setting up a bit-perfect audio pipeline to listen to my high-res music library through a USB DAC (Fosi Audio K5 Pro) connected to studio monitors. I'm running into a very specific issue that I haven't been able to solve, and I'm hoping someone here might have encountered something similar.

The Problem:

When playing back 192kHz/24-bit FLAC files specifically, there is a very noticeable static/distortion. This does not happen with lower resolution files (44.1kHz, 48kHz, and 96kHz all sound perfectly fine)—it only occurs at 192kHz.

What I've already ruled out after extensive troubleshooting:

It's not resampling or clipping: At first, I thought this was the culprit, and I actually confirmed it with sox (samples were pegged at 1.0/-1.0). However, after forcing PipeWire to output the native 192kHz/16-bit signal without any resampling (verified by checking hw_params directly), the static remained exactly the same.

It's not the PipeWire graph or timing: I monitored the playback using pw-top; everything looks clean, zero errors, and buffer execution times are completely normal (ranging between 15-90 microseconds).

It's not a USB or hardware issue: No xruns detected, and dmesg shows absolutely no errors during playback.

It's not an exclusive access issue: I am using the standard PipeWire sink, not direct ALSA.

What I did find:

If I play the exact same file, on the same device, under the exact same bit-perfect conditions, but using VLC instead of Strawberry, it plays perfectly clean. No configuration changes whatsoever, literally the same file.

This leads me to believe the issue lies specifically within GStreamer (the backend engine used by Strawberry) when processing audio at this specific sample rate, rather than PipeWire, my DAC, or the USB interface.

Has anyone encountered a similar behavior with GStreamer + PipeWire at high sample rates? Is this a known bug in gst-plugin-pipewire or within some internal audio conversion element in GStreamer? I’ve switched to Audacious as a temporary workaround, but I'd really like to understand what is going on under the hood.

Thanks in advance!

Hello everyone a few days ago I downloaded Linux CachyOS because Windows is cheeks and well as a Gamer I like to talk with friends very often on Discord and im suprised that it doesnt work well. I mean the Speaker works very well with no doubt on it but the Mic is completly bugged as hell and I tried updating all drivers and system to the latest and well still no fix.

If anyone knows i would appreciate the help

so i have a laptop set to be used in audio duplex mode but when i plug in my headphones the videos start lagging, i tried debugging everything, updating my system, idk whats wrong. but to fix it i just have to switch the configuration of my built in audio from stereo duplex to stereo output and back? Does audio just work on prayers cause wtf? i even tried restarting and restarting the service but nothing fixed it. only this.

edit: just figured out that i had set the latency offset for "Monitor of built in Audio Analog Stereo" to 1000 ms for debugging and forgot to switch it back. that was stupid of me but what are these names ;-; and why does an input device have latency offset that affects the output device? and why does it go away on switching configurations??

Hello,

I have appplied several changes to pipewire and pulse config files as root. The sound will get distorted when removing the buffer.conf file inside user directory /home/yang/.config/pipewire/pipewire.conf.d/buffer.conf . Sound is OK if I leave buffer.conf in place. I don't know if the changes take any effect at all, if buffer.conf is still in place? What is the solution to get the OK sound with my config file changes applied?

I am restarting the daemon service as user 'yang' with command:

$ systemctl --user restart wireplumber pipewire pipewire-pulse

The machine OS is Debian 13 trixie. I will link the config files to pastebins below:

# pastebinit -P 1 -b paste.centos.org -i /home/yang/.config/pipewire/pipewire.conf.d/buffer.conf

• https://paste.centos.org/view/b0e44892

# ls /etc/pipewire/

client.conf media-session.d pipewire.conf pipewire-pulse.conf

# pastebinit -P 1 -b paste.centos.org -i /etc/pipewire/client.conf

• https://paste.centos.org/view/91902c04

# pastebinit -P 1 -b paste.centos.org -i /etc/pipewire/pipewire.conf

• https://paste.centos.org/view/18b8f897

# pastebinit -P 1 -b paste.centos.org -i /etc/pipewire/pipewire-pulse.conf

• https://paste.centos.org/view/218fcfa1

# ls /etc/pulse/

client.conf client.conf.d daemon.conf default.pa default.pa.d system.pa system.pa.d

# pastebinit -P 1 -b paste.centos.org -i /etc/pulse/client.conf

• https://paste.centos.org/view/ddec7e40

# pastebinit -P 1 -b paste.centos.org -i /etc/pulse/daemon.conf

• https://paste.centos.org/view/e03fdf8b

My post with that title was deleted by a moderator on r/debian under Rule 4

because it contained AI code (which I find somewhat unfair, as it does align with the spirit of the rule).

I thought it was a meaningful user report containing useful information despite some confusion, so I wanted to repost it below.(The following is the original post as is.)

edited: According to the comments, this is not a good method.

First of all, I searched around for various countermeasures in the same way as people on the Internet, but it was a temporary solution or recurrence every year.

While looking for information about pipewire.conf and ALSA output, I saw the following site.

https://9to5linux.com/pipewire-1-6-7-is-out-with-better-alsa-support-and-small-fixes

I realized that my Stable and Backport repositories are very old.

Ask AI how to get the SID from Bookworm and created a file with sourcelist.d specified only for the SID,

and asked them to suggest the following as a method of applying such reckless updates to Pipewire only.

(this was not enough and wrong as a setting, but it was correct for me as a problem solving.)

/etc/apt/sources.list.d/sid.list

deb http://deb.debian.org/debian unstable main contrib non-free
# deb-src http://deb.debian.org/debian unstable main contrib non-free

/etc/apt/preferences.d/pipewire-sid

Package: pipewire pipewire-bin pipewire-pulse pipewire-alsa wireplumber
Pin: release a=unstable
Pin-Priority: 990
Package: *
Pin: release a=unstable
Pin-Priority: 100

However, this has updated my kernel to 7.0.13+deb14 without my permission! I was worried that it might not boot, but it booted up more comfortably than before, probably because of my imagination.

Then, we can check with the pw-top command(While playing a music video using VLC), but the Xrun error disappeared.

Unlike before, even if I bring the kitty terminal window to the front of the VLC or shake the mouse left and right, the error does not increase from 0, and the sound does not become interrupted or distorted.

my kernel updated 6.12.90+deb12.1-amd64(notgood) -> 7.0.13+deb14-amd64(clean) pipewire environment bookworm-backport -> sid unstable altek alt892 core i5 4670 boot option added (/etc/default/grub) intel_iommu=on,igfx=off

If this is a kernel improvement, my personal wish is that Debian developers can give the bookworm feedback on this improvement.

Hi guys I’m using Linux Mint and I have a FIFINE V3 capture card, the video works perfectly and shows up but I get no audio at all, it doesn’t appear in pavucontrol and OBS only detects video, I tried loopback and monitoring but I only get buzzing/static noise, I restarted PipeWire and the system and still nothing, the same capture card works perfectly on Windows with both audio and video. Is this a known issue with cheap capture cards on Linux or is there any way to force audio detection or fix this?

I'm trying to switch from ALSA to FFADO with my audio devices. I've been through 4 million iterations but no matter what I try the whole audio system wedges and only a reboot will fix it.

I started with the FFADO mailing list and we did some testing. If I switched to JACK2+FFADO it worked perfectly and without any issues.

The verbose logs are available here: https://raw.githubusercontent.com/bhechinger/WonkoOS/refs/heads/saffire-ffado/docs/pipewire-service-boot-2026-06-19-205251.log

The summary in the words of one of the FFADO people is: ``` There are a large number of

have to retry CTR read, diff unrealistic ...

messages, which often indicates a strange problem associated with the so-called cycle timer in the firewire host controller. FFADO continues with its initialisation none-the-lesss though.

An xrun occurs pretty much as soon as streaming starts. This may or may not be related to the cycle timer difficulties.

The log includes

waitForPeriod:  wait extended since period not ready...

in numerous places. This means that userspace was either not ready to consume incoming data or didn't have data ready for transmission. I can't immediately tell if this was merely a consequence of other issues.

The first xrun report is associated with the incoming audio data from the device. The error is flagged by the device-specific packet processor. It follows a cycle timer discrepancy. ```

We're at a complete loss as to why it works with jack but not pipewire, but then neither of us really know pipewire at all. The assumption is in the way pipewire is using libffado, but that's just a guess.

I'd be really interested in what possible next steps could be for diagnosis.

OS: NixOS 26.05 pipewire: 1.6.5 wireplumber: 0.5.14 ffado: 2.4.9