How to use Pipewire to replace PulseAudio?

[anna328p]

Issue description

I have been trying to use PipeWire as a PulseAudio replacement. Here are some things that I have tried:

1. Enabling the pipewire service, disabling the pulseaudio server. This works, outputs audio, and I can control it with qjackctl. However, this requires running every application prefixed with pw-pulse as they do not load the Pulse emulation libraries provided by Pipewire.
2. I tried replacing pulseaudio with pipewire in an overlay. This went poorly.

What would I need to do to run pipewire as my audio server?

[eadwu]

pw-pulse looks like it just sets LD_LIBRARY_PATH so probably just setting up symlinks with lower priority would work.

[anna328p]

pw-pulse looks like it just sets LD_LIBRARY_PATH so probably just setting up symlinks with lower priority would work.

how would I do this? I haven't worked with audio systems on NixOS before.

[eadwu]

You can use something like

stdenv.mkDerivation {
  pname = "pipewire-libs";
  inherit (pipewire) version src;

  dontBuild = true;

  installPhase = ''
    mkdir -p $out/lib
    cp -pdv ${pipewire.lib}/lib/pipewire-*/pulse/* $out/lib
  '';
}

and include it in systemPackages with lowPrio. Though I never made a lot of progress on testing out Pipewire so can't test it.

[minijackson]

It seems the functionnality you want is implemented in PR #93725. With this module you wouldn't need to run programs through pw-pulse, etc.

[anna328p]

Will be fixed by #93725.

[jansol]

The abovementioned PR has been merged. Pipewire can be used with the following in configuration.nix:

# Not strictly required but pipewire will use rtkit if it is present
security.rtkit.enable = true;
services.pipewire = {
  enable = true;
  # Compatibility shims, adjust according to your needs
  alsa.enable = true;
  alsa.support32Bit = true;
  pulse.enable = true;
  jack.enable = true;
};

When the pulse compatibility layer is enabled most applications should see your audio devices like they would with native pulseaudio. Steam and Discord are known to not detect the emulation layer for now. And you'll want to at least check with qjackctl or patchage to make sure your applications are connected to useful inputs & outputs (by default they weren't on my system).

[ashkitten]

@jansol is there an open issue about using steam and discord with pipewire? (and lutris, i believe)

[jtojnar]

The pulse-server introduced in 0.3.14 might be of interest #102514

[jansol]

Opened #102547 for tracking the status of pipewire and its integrations in one place. (should probably really be a wiki page)

[jansol]

@anna328p why reopen? Most apps are working out of the box with the pulse emulation now. Unless they depend directly on the native libpulseaudio.so in their wrapper scripts or the like.

[anna328p]

@anna328p why reopen? Most apps are working out of the box with the pulse emulation now. Unless they depend directly on the native libpulseaudio.so in their wrapper scripts or the like.

I reopened this for the Steam and Discord issues.

[eadwu]

From what I'm understanding, the solution you want depends on the upstream to support it, stemming from the fact that you are redirecting the ALSA output to Pulseaudio, which Pipewire does not have full compatibility with. If you're trying to mainly use Pipewire, I would recommend redirecting the output to Pipewire and using the library shims to run Pulseaudio/Jack applications, or manually executing workarounds for the applications (probably something like PIPEWIRE_PROPS) to force a sink to become available and direct it's input/output to your capture output or audio output.

[jansol]

Upstream does have a module to let the pipewire server act as a fake pulseaudio server (pulse-bridge). I tried starting pipewire manually with that module enabled and lo and behold, discord, steam and all steam games I tried worked without any further involvement. So what needs to be done is as described in #102514 : we need a nixos option that generates a pipewire config that enables pulse-bridge.

[jansol]

Upstream just simplified our job a lot by generating a separate systemd service to load pulse-bridge, see #102547 (comment)

[ashkitten]

there is no reason to have two issues open for the same thing, especially if comments are just going to be duplicated across anyway. #102547 is the tracking issue for pipewire as a whole.