PipeWire: Difference between revisions

==Configuring PipeWire==

<syntaxhighlight lang="nix">

   security.rtkit.enable = true;

   services.pipewire = {

     alsa.support32Bit = true;

     pulse.enable = true;

     #jack.enable = true;

   };

</syntaxhighlight>

==Bluetooth Configuration==

PipeWire can be configured to use specific codecs, by default all codecs and most connection modes are enabled, see [https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/bluetooth.html#monitor-properties this link] for precise details of which connections modes are enabled by default. The mSBC codec provides slightly better sound quality in calls than regular HFP/HSP, while the SBC-XQ provides better sound quality for audio listening. For more information [https://www.guyrutenberg.com/2021/03/11/replacing-pulseaudio-with-pipewire/ see this link].

<syntaxhighlight lang="nix">

     };

   };

<syntaxhighlight lang="nix">

All protocols (Pulseaudio/JACK) are now talking to the PipeWire protocol and are managed by the PipeWire daemon (therefore, applications can be managed by both Pulseaudio and JACK tools). For that reason, all graphical tools used for these protocols can be used:

==Advanced Configuration==

This is especially convenient if the user has a multi-channel (8+, or something "weird" like 2x2, 3x2) soundcard that keeps confusing applications with too many channels or a bad channel layout.

In order to load the script on startup, it can be added to <code>~/.xprofile</code> or the specific DE/WM autostart config. Similarly, a one-shot user service can be created that runs the script.

Audio production and rhythm games require lower latency audio than general applications. PipeWire can achieve the required latency with much less CPU usage compared to PulseAudio, with the appropriate configuration.

The minimum period size controls how small a buffer can be. The lower it is, the less latency there is. PipeWire has a value of 32/48000 by default, which amounts to 0.667ms. It can be brought lower if needed:

<strong>NOTE</strong>: Every setup is different, and a lot of factors determine your final latency, like CPU speed, RT/PREEMPTIVE kernels and soundcards supporting different audio formats. That's why 32/48000 isn't always a value that's going to work for everyone. The best way to get everything working is to keep increasing the quant value until you get no crackles (underruns) or until you get audio again (in case there wasn't any). This won't guarantee the lowest possible latency, but will provide a decent one paired with stable audio.

Applications using the Pulse backend have a separate configuration. The default minimum value is 1024, so it needs to be tweaked if low-latency audio is desired.

</syntaxHighlight>

PipeWire can run on a headless device (without a GUI) such as a Raspberry Pi connected to a speaker. In that case, it may be preferable to start PipeWire on boot and keep it running rather than only running during an interactive login session. Among other things, this helps prevent a race condition that may occur when socket activation fails to initialize  audio devices in time for their first use, leading to one-time errors after reboots. The following additional configuration facilitates this:

Despite early activation, you may still experience a race condition that prevents audio from working if you play media immediately after a new login such as running an SSH command. If this occurs, try introducing a short delay (e.g. <code>sleep 5</code>) before invoking the media player application.

==Troubleshooting==