use Pipewire instead of PA

Is your feature request related to a problem? Please describe.
This is a little related to MIDI and JACK support but it can live as it's own issue.

Describe the solution you'd like
Currently, the team considered PulseAudio, which is fine by itself, however, if you factor in Flatpaks in someone's WSL setup or JACK support, PA wouldn't really be a good system for this. Hence, Pipewire should be installed instead since it handles both use cases for PA and JACK.

Describe alternatives you've considered
A custom CBL-Mariner Distro would have done the job but I don't know how well it'll work since I believe the current implementation relies on PA but it should work.

Ayase Minori (@sr229)

Fedora enabled Wayland and Pipewire by default. There is a great chance that Ubuntu 22.04 will come with both enabled by default. It's about time to switch to the modern desktop technologies.

Ayase Minori (@sr229) A better title for this would be: "Enable/Use Pipewire by default".

This would be nice to run JACK programs through pipewire.

What would be the command to replace pulseaudio with pipewire in this file? https://github.com/microsoft/wslg/blob/main/WSLGd/main.cpp

Pipewire would need the RDP sink/source implemented for it to work.

Do we have any way allready to make Pipewire or Jack work in WSLg?

Is it possible to setup pipewire's pulse audio tunnel https://docs.pipewire.org/page_module_pulse_tunnel.html? Seems promising, if the existing WSL solution is using pulse as server on windows side? Anyone tried?

Seems as Ubuntu 22.10 will get pipewire by default, so it is probably time to have a solution here :)

Is there any update on this?

One would also be able to use PipeWire for obtaining the camera contents (and being able to do so across several apps at once, at that!) and grab the screen contents for screensharing too. PipeWire isn't just audio.

One would also be able to use PipeWire for obtaining the camera contents (and being able to do so across several apps at once, at that!) and grab the screen contents for screensharing too. PipeWire isn't just audio.

When I historically made this issue, the main focus was for PA/JACK. I wasn't aware PW supported most multimedia interfaces, which is a nice thing to know.

Is it possible to setup pipewire's pulse audio tunnel https://docs.pipewire.org/page_module_pulse_tunnel.html? Seems promising, if the existing WSL solution is using pulse as server on windows side? Anyone tried?

Seems as Ubuntu 22.10 will get pipewire by default, so it is probably time to have a solution here :)

We'll have to implement some support in the system distro as well (the Linux system in charge of forwarding graphical requests to RDP in WSL), so someone either:

Adds support by adding PW in the system distro, removing PA and measure the impact of such changes on some legacy PA-reliant programs
Have two versions of the WSLg system distro side by side to measure behavior.

Adds support by adding PW in the system distro, removing PA and measure the impact of such changes on some legacy PA-reliant programs

Not an issue. PipeWire provides pipewire-pulse, pipewire-jack, and pipewire-alsa. I believe it also provides an LD_PRELOAD for v4l2 applications.

Worth noting that PipeWire has released version 1.0.0

To copy from their release notes:

"PipeWire represents the next evolution of audio handling for Linux, taking
the best of both pro-audio (JACK) and desktop audio servers (PulseAudio) and
linking them into a single, seamless, powerful new system."
- Paul Davis, JACK and Ardour author

"PipeWire is a worthy successor to PulseAudio, providing a feature set
closer to how modern audio hardware works, and with a security model
with today's application concepts in mind. Version 1.0 marks a
major milestone in completing the adoption of PipeWire in the standard
set of Linux subsystems. Congratulations to the team!"
- Lennart Poettering, Pulseaudio and systemd author

Any plans on this? :P

PipeWire 1.4 is released, what are the WSLg roadmap to move to PipeWire?

+2026

So, does Microsoft need to fork https://gitlab.freedesktop.org/pipewire/pipewire and modify something, just like with https://github.com/microsoft/PulseAudio-mirror ?

I noticed this issue because the developers of Audacity refused to fix the bug on wslg because they disliked Pulse Audio. I'm referring to audacity/audacity#10236 .

Kind of off-topic question, but: Where do you see that the Audacity developers did not like PulseAudio? I see only this and it seems like a valid point to me: "These libraries are intentionally left to the system to provide, and bundling them in the breaks things"

(And problems like these are unfortunately quite common with AppImages.)

Kind of off-topic question, but: Where do you see that the Audacity developers did not like PulseAudio? I see only this and it seems like a valid point to me: "These libraries are intentionally left to the system to provide, and bundling them in the breaks things"

(And problems like these are unfortunately quite common with AppImages.)

This is a bit off-topic, but considering that I found they didn't reply to me within a week and their GitHub account wasn't hacked, this is the only conclusion I can draw.

Although this seems like a dependency that should be installed beforehand in https://github.com/ubuntu/WSL , it would seem strange to put code into Ubuntu WSL without making changes on the WSL side, given that the Pulse Audio plugin's code is imported from the WSLg repository. By the way, I know that AppImage has never been a true sandbox, but Audacity only has third-party snapcraft and flatpak packages, and the disconnect from the official repository often causes problems.

The Audacity developers don't really consider Pulse Audio a typical audio system.

Also, I think it's probably fair for Audacity to assume that the user has a functioning sound system set up.

Putting Audacity aside, to be honest, I'm confused by the content of https://github.com/microsoft/wslg/blob/main/azure-pipelines.yml . The Azure Pipeline configuration file doesn't have dedicated unit tests; it completely relies on the result of component builds to determine wslg's availability? And testing Azure requires me to register a company in the real world and open an account on https://www.azure.cn/ ? I personally find it hard to believe that GitHub didn't provide Microsoft with the highest-performing GitHub Actions Runner.

Have two versions of the WSLg system distro side by side to measure behavior.

To be honest, I find it hard to imagine that wslg is only tested by humans and not by writing unit tests. azure-pipelines.yml seems completely unconcerned about this.

If Microsoft hadn't forked the git repository for PipeWire and WirePlumber, writing .patch files in wslg would have been quite a pain.

Using Azure instead of GitHub Actions for CI is just as agonizing.

diff --git a/src/modules/meson.build b/src/modules/meson.build 
 index 3d97bb5..e6f7b15 100644 
 --- a/src/modules/meson.build 
 +++ b/src/modules/meson.build 
 @@ -11,6 +11,7 @@ module_sources = [ 
    'module-combine-stream.c', 
    'module-echo-cancel.c', 
    'module-example-filter.c', 
 +  'module-wslg-rdp.c', 
    'module-example-sink.c', 
    'module-example-source.c', 
    'module-fallback-sink.c', 
 @@ -462,6 +463,22 @@ pipewire_module_example_sink = shared_library('pipewire-module-example-source', 
    install_rpath: modules_install_dir, 
    dependencies : [spa_dep, mathlib, dl_lib, pipewire_dep], 
  ) 
 + 
 +pipewire_module_wslg_rdp_sink = shared_library('pipewire-module-wslg-rdp-sink', 
 +  [ 'module-wslg-rdp.c' ], 
 +  c_args : ['-DWSLG_RDP_MODE_SINK'], 
 +  include_directories : [configinc], 
 +  install : true, 
 +  install_dir : modules_install_dir, 
 +  install_rpath: modules_install_dir, 
 +  dependencies : [spa_dep, mathlib, dl_lib, pipewire_dep], 
 +) 
 + 
 +pipewire_module_wslg_rdp_source = shared_library('pipewire-module-wslg-rdp-source', 
 +  [ 'module-wslg-rdp.c' ], 
 +  c_args : ['-DWSLG_RDP_MODE_SOURCE'], 
 +  include_directories : [configinc], 
 +  install : true, 
 +  install_dir : modules_install_dir, 
 +  install_rpath: modules_install_dir, 
 +  dependencies : [spa_dep, mathlib, dl_lib, pipewire_dep], 
 +)

PipeWire version 1.6 has just been released.

https://www.phoronix.com/news/PipeWire-1.6

If WSL2 works fine, we can try linking PipeWire to Microsoft Pulse SoundServer

create a config file ~/.config/pipewire/pipewire.conf.d/50-wsl-virtual-hardware.conf

context.modules = [
    { name = libpipewire-module-pulse-tunnel
      args = {
          tunnel.mode = "sink"
          pulse.server.address = "unix:/mnt/wslg/PulseServer"
          pulse.latency = 100
          stream.props = {
              node.name            = "WSLg-Tunnel-Sink"
              node.description     = "Microsoft RDP Sound Tunnel"
              
              clock.rate           = 44100
              node.force-rate      = 44100
              
              node.suspend-on-idle = false
              session.suspend-on-idle = false
              node.always-process  = true
          }
      }
    }
]

This works fine on my Ubuntu 26.04 on WSL2

suspend-on-idle is necessary, or you'll lose sound after playing once.

25. PipeWire version 1.6 has just been released.
https://www.phoronix.com/news/PipeWire-1.6

I made some minor updates to Replace PulseAudio with PipeWire/WirePlumber audio stack in WSLg #1418 to resolve merge conflicts; however, since there has been no further response from Microsoft staff, I haven't updated it to PipeWire 1.6—mainly because I don't know what they are doing in their internal CI.
I don't see any way to test PipeWire via Flatpak. Given that the pull request at common: Impl client-side authorization caching in built-in polkit agent flatpak/flatpak#6505 has gone unreviewed for over six months—and the Flatpak experience on WSL remains poor—one could argue from another perspective that Flatpak discriminates against WSL users.

Navigation Menu

Repository navigation

use Pipewire instead of PA #290

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

use Pipewire instead of PA #290

Description

Activity

Zingam commented on Jun 15, 2021

Aerocatia commented on Nov 22, 2021

Biswa96 commented on Nov 22, 2021

Aerocatia commented on Nov 23, 2021

capoei commented on Mar 4, 2022

robberos commented on May 31, 2022

i2 commented on Mar 4, 2023

orowith2os commented on Sep 24, 2023

sr229 commented on Sep 25, 2023

sr229 commented on Sep 25, 2023

orowith2os commented on Sep 25, 2023

jthoward64 commented on Nov 27, 2023

Beryesa commented on Aug 20, 2024

ohault commented on Mar 6, 2025

razamatan commented on Jan 11, 2026

linghengqian commented on Jan 27, 2026

AsciiWolf commented on Jan 27, 2026

linghengqian commented on Jan 27, 2026

linghengqian commented on Jan 28, 2026

ohault commented on Feb 19, 2026

pffang commented on Sep 20, 2026

linghengqian commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions