PipeWire/Troubleshooting - ArchWiki

Jump to content

# PipeWire/Troubleshooting

From ArchWiki
< PipeWire

Before continuing check the obvious ones:

1. Did you select the right sound card?
2. Is the volume up (soft- and hardware)?
3. Are the cables connected to the right ports?
4. Is the USB sound card connected directly to the computer?
5. Have you turned up the microphone volume, connected it and enabled the XLR phantom amplifier?
6. Is the surround sound messed up? Then first uninstall UCM configurations package alsa-ucm-conf. See PulseAudio/Examples#Disabling UCM/"HiFi".
7. Restart `pipewire.service` and `pipewire-pulse.service` user unit.

## Volume

### No sound in various applications but sound in browser

The factual accuracy of this article or section is disputed.

Reason: Issue's root cause is guessed not verified. Only application mute issue? (Discuss in Talk:PipeWire/Troubleshooting)

Use `mpv` to check for installed codecs working

    $ mpv --ao=alsa test_file.mpv
    $ mpv --ao=pcm test_file.mpv
    $ mpv --ao=jack test_file.mpv
    $ mpv --ao=pulse test_file.mpv
    $ mpv --ao=openal test_file.mpv

If some or all of the above tests produce sound and the following does not

    $ mpv --ao=pipewire test_file.mpv

it might be that `pipewire` channel is muted. Install `pavucontrol` and run it.

Select the appropriate source in the Configuration tab, select it again in the Output device tab and then use Mute button to mute and unmute the source while `mpv --ao=pipewire test.mp4` video is running.

Alternatively, remove `~/.local/state/wireplumber/` and restart pipewire `systemctl --user restart pipewire pipewire-pulse wireplumber.service`

### Low volume

After replacing PulseAudio with Pipewire, sound may work fine, but after a reboot, the volume becomes intolerably low.

Open `alsamixer`, use `F6` to select the proper soundcard, and make sure the ALSA volumes are at 100%. `alsactl` should maintain this setting after reboot.

### Device volume for SDDM and LightDM users is not restored on login

If you use SDDM or LightDM and notice that your audio volume level is not properly restored after logging in, mask PipeWire for the display manager's user, since WirePlumber running under the display manager can interfere with your user's WirePlumber session.

    # systemctl --user -M user@ mask pipewire.socket

Replace `user` with `sddm` for SDDM or `lightdm` for LightDM.

For more details, see this Debian Wiki article.

## Microphone

### Microphone is not detected by PipeWire

If you are using a built in microphone of a laptop, or connected using the headphone jack: First make sure the analog input is enabled in the profile in use. You can check the profile in pavucontrol (and possibly in your desktop environment sound settings). In pavucontrol, on the Configuration tab, under "Built-in Audio" (or similar) make sure "Analog Stereo Duplex" is selected. If you use an advanced sound setup such as 5.1 or sound over HDMI, make sure a profile that includes "+ Analog Stereo Input" is selected.

PipeWire's `alsa-monitor` module uses alsa-card-profiles to detect devices by default. If this is not working for you, try to turn off `api.alsa.use-acp`, or optionally turn on `api.alsa.use-ucm` in wireplumber:

    /etc/wireplumber/wireplumber.conf.d/alsa-config.conf (or ~/.config/wireplumber/wireplumber.conf.d/alsa-config.conf)

    monitor.alsa.properties = {
      # Use ALSA-Card-Profile devices. They use UCM or the profile
      # configuration to configure the device and mixer settings.
      # alsa.use-acp = true
      # Use UCM instead of profile when available. Can be disabled
      # to skip trying to use the UCM profile.
      alsa.use-ucm = true
    }

With pipewire-media-session:

    /etc/pipewire/media-session.d/alsa-monitor.conf (or ~/.config/pipewire/media-session.d/alsa-monitor.conf)

    ...
    rules = [
        {
            ...
            actions = {
            update-props = {
                ...
                api.alsa.use-acp = false
    ...

Then, restart WirePlumber and check available devices:

This article or section is out of date.

Reason: Option `--list-targets` is no longer available in the recent versions of `pw-record`; in order to list objects use either `wpctl status` or `pw-cli ls` or `pw-dump` instead. (Discuss in Talk:PipeWire/Troubleshooting)

    $ pw-record --list-targets

    Available targets ("*" denotes default): 62
    	58: description="Built-in Audio" prio=1872
    	60: description="Built-in Audio" prio=2000
    *	62: description="Built-in Audio (Loopback PCM)" prio=1984

An alternative solution suggested in this PipeWire issue is to add the microphone manually. First of all, make sure the microphone is detected by ALSA.

    $ arecord -l

    **** List of CAPTURE Hardware Devices ****
    card card_number: card_name, device device_number: device_name
      ...

Choose your microphone from the list, and to further test the microphone, run the following commands.

    $ arecord --duration=5 --format=dat --device=hw:card_number,device_number test-mic.wav # record from the mic
    $ aplay test-mic.wav # play it

If the microphone is working with `arecord`, but not detected by PipeWire, try to add a configuration file to manually add this device.

    /etc/pipewire/pipewire.conf.d/microphone.conf (or ~/.config/pipewire/pipewire.conf.d/microphone.conf)

    context.objects = [
        { factory = adapter
            args = {
                factory.name           = api.alsa.pcm.source
                node.name              = "microphone"
                node.description       = "Undetected Microphone"
                media.class            = "Audio/Source"
                api.alsa.path          = "hw:card_number,device_number"
            }
        }
    ]

And then restart PipeWire to reload the configuration.

## Audio quality

### Crackling due to powersaving

Crackling may be caused by the wikipedia:HECI Controller being power managed. Runtime PM may be diabled with powertop.

### Audio is distorted

- For microphones, try navigating to the card that is having issues after running `alsamixer` and use the arrow keys to reduce any "Mic Boost" or "Internal Mic Boost" options.
- Follow #Changing the default sample rate, reducing the sample rate to `44100` (44.1 kHz).

### Changing the default sample rate

By default PipeWire sets a fixed global sample rate of 48kHz. If you need to change it, you can set a new default (although it isn't recommended):

    /etc/pipewire/pipewire.conf.d/sample-rate.conf (or ~/.config/pipewire/pipewire.conf.d/sample-rate.conf)

    context.properties = {
        default.clock.rate = sample_rate
    }

This, however, isn't recommended as this will affect latencies as the quantum values aren't re-calculated automatically. You will have to change these yourself if you want to preserve the same ratio. To quote the documentation:

  The default clock rate determines the real time duration of the min/max/default quantums. You might want to change the quantums when you change the default clock rate to maintain the same duration for the quantums.

Keep in mind that the rates of the streams will remain the same. All that PipeWire will be doing here is resampling to meet your new rate. So the 48kHz streams that would've been left unaltered will now be resampled.

If you have gear that can handle different sample rates, it is instead recommended to leave the defaults and follow as indicated here: #Changing the allowed sample rate(s)

### Changing the allowed sample rate(s)

PipeWire can also change dynamically the output sample rates supported by your DAC. The sample rate follows the sample rate of the audio stream being played. For example:

    /etc/pipewire/pipewire.conf.d/sample-rate.conf (or ~/.config/pipewire/pipewire.conf.d/sample-rate.conf)

    context.properties = {
        default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 352800 384000 ]
    }

Say the default sample rate is `48000`, which is the default. Normally if a stream outputs audio at 44100Hz (i.e. a music player playing a song at CD quality), Pipewire will resample the stream to 48kHz. However, if you have `44100` in this list, Pipewire will instead do the following. Pipewire will see that the stream is at 44100Hz, then check if `44100` is in the allowed rates and that the receiving output device (i.e. DAC) supports the rate. In such case, the DAC will play the song losslessly. If the rate isn't in the list or if the DAC doesn't support the rate, PipeWire will simply fall back to resampling the stream to the default sample rate.

According to the developer: "PipeWire allows up to 16 different sample rates and will switch when possible". That means, with configuration above, no resampling is done when supported. Since PipeWire 0.3.61 up to 32 different sample rates can be configured.

### Getting allowed sample rate(s)

Consult your hardware manual for supported values of your DAC. Supported rates by the kernel driver codec are listed with the following command.

    $ grep -E 'Codec|Audio Output|rates' /proc/asound/card*/codec#*

If your DAC does not report codec information, you can try to obtain supported rates like this:

    $ grep -m1 -Hn "" /proc/asound/card?/stream? | tee /dev/tty | awk -F':' '{print $1}' | xargs grep 'Rates'

Note Although your DAC chip may report rates higher than advertised in specification, some of them were designed for exotic modes like USB to I2S

### Checking currently used sample rate

To check which output sample rate is being used for a card run:

    $ grep rate: /proc/asound/card?/pcm??/sub?/hw_params

    /proc/asound/card1/pcm0p/sub0/hw_params:rate: 96000 (96000/1)

In `pcm0p` or `pcm0c` `c` is short for "capture" and `p` is for "playback".

Command:

    $ pw-top

also shows currently used sample rate for each card and audio stream.

Tip If your DAC will not switch to a higher rate, after setting default.clock.allowed-rates, it may mean that system cannot read rates supported by DAC. In such case you can still try setting default.clock.rate

## Hardware and cards

### Issues with JBL Quantum 350 Wireless and Discord

Symptom: Audio not working when Discord initiates the sound output / configuration. If existing sound is playing then Discord audio works. An error like

    spa.alsa: front:0p: (125 suppressed) snd_pcm_avail after recover: Broken pipe

will be present in the journalctl.

There are (at least) two possible solutions, one is increasing `api.alsa.headroom` (e.g. setting it to 512) or setting an appropriate `api.alsa.start-delay`. An example doing this for a JBL Quantum 350 wireless device is

    ~/.config/wireplumber/wireplumber.conf.d/52-jbl-quantum-350-discord-fix.conf

    monitor.alsa.rules = [
       {
         matches = [
           {
             node.name = "alsa_output.usb-JBL_JBL_Quantum350_Wireless-00.analog-stereo"
           }
         ]
         actions = {
           update-props = {
             api.alsa.start-delay = 500
           }
         }
       }
     ]

and restart the `wireplumber.service` user unit on the machine.

### XiiSound / HAVIT Fuxi-H3 (040b:0897)

This USB headset has several quirks with PipeWire and WirePlumber:

- Audio only works at 100% volume — the hardware volume range is too narrow (0.00dB to 0.39dB) and PipeWire's dB mapping collapses any lower volume to silence.
- Left channel is silent — the device exposes a secondary ALSA mixer control (`PCM,1`, numid=10) for the left channel that WirePlumber does not initialize, leaving it at 0%.
- Microphone initializes muted — WirePlumber may start the capture source with mute enabled.

Fix 1 — Force software mixer:

Create

    ~/.config/wireplumber/wireplumber.conf.d/51-fuxi-h3-fix.conf

    monitor.alsa.rules = [
       {
         matches = [
           {
             device.name = "alsa_card.usb-XiiSound_Technology_Corporation_Fuxi-H3-00"
           }
         ]
         actions = {
           update-props = {
             api.alsa.soft-mixer = true
             api.alsa.ignore-dB = true
             api.alsa.split-enable = false
           }
         }
       }
     ]

and restart the `wireplumber.service` user unit on the machine.

Fix 2 — Restore left channel:

    $ amixer -c 0 cset numid=10 100

Fix 3 — Unmute microphone:

    $ pactl set-source-mute alsa_input.usb-XiiSound_Technology_Corporation_Fuxi-H3-00.mono-fallback 0

Persist across reboots:

    # alsactl store 0

### No sound devices show up in KDE Plasma

PipeWire clients (including the desktop environment) may rely on the XDG_RUNTIME_DIR environment variable to connect to the PipeWire daemon. [1] If you experience no sound devices immediately after login, it may be because this variable has manually been set to the wrong path.

Although this be resolved by manually restarting PipeWire, other issues can still occur such as being unable to screen share in Chromium (with `pipewire context failed`). `XDG_RUNTIME_DIR` is automatically set by pam_systemd(8), so you should remove any instances of it being set in your initialization files.

### No sound during streaming to RAOP devices (Sonos etc.)

Set up mDNS hostname resolution using either Avahi or systemd-resolved.

### Missing realtime priority/crackling under load after suspend

This article or section is being considered for removal.

Reason: Said bug was fixed after moving to the new freedesktop.org repo in 2023. (Discuss in Talk:PipeWire/Troubleshooting)

Due to a bug from 2011 in rtkit, suspend events cause PipeWire's realtime priority to be revoked and not restored. To disable the protection which causes this, edit `rtkit-daemon.service`:

    /etc/systemd/system/rtkit-daemon.service.d/override.conf

    [Service]
    ExecStart=
    ExecStart=/usr/lib/rtkit-daemon --no-canary

Then restart the `rtkit-daemon.service` unit and `pipewire.service` user unit, along with the media session service.

### Simultaneous output to multiple sinks on the same sound card

Create a copy of `/usr/share/alsa-card-profile/mixer/profile-sets/default.conf` so that changes persist across updates. Here we define a profile joining the two default mappings for Analog and HDMI.

    /usr/share/alsa-card-profile/mixer/profile-sets/multiple.conf

    [General]
    auto-profiles = no

    [Mapping analog-stereo]
    device-strings = front:%f
    channel-map = left,right
    paths-output = analog-output analog-output-lineout analog-output-speaker analog-output-headphones analog-output-headphones-2
    paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headphone-mic analog-input-headset-mic
    priority = 15

    [Mapping hdmi-stereo]
    description = Digital Stereo (HDMI)
    device-strings = hdmi:%f
    paths-output = hdmi-output-0
    channel-map = left,right
    priority = 9
    direction = output

    [Profile multiple]
    description = Analog Stereo Duplex + Digital Stereo (HDMI) Output
    output-mappings = analog-stereo hdmi-stereo
    input-mappings = analog-stereo

Then configure your session manager to use the new card-profile for matching devices. Identifying information can be found using `pw-dump` or wpctl.

For wireplumber:

    /etc/wireplumber/wireplumber.conf.d/alsa-custom.conf (or ~/.config/wireplumber/wireplumber.conf.d/alsa-custom.conf)

    monitor.alsa.rules = [
      {
        matches = [
          {
            device.nick = "HDA Intel PCH"
          }
        ]
        actions = {
          update-props = {
            api.alsa.use-acp = true
            api.acp.auto-profile = false
            api.acp.auto-port = false
            device.profile-set = "multiple.conf"
            device.profile = "multiple"
          }
        }
      }
    ]

For pipewire-media-session:

    /etc/pipewire/media-session.d/alsa-monitor.conf (or ~/.config/pipewire/media-session.d/alsa-monitor.conf)

    rules = [
        {
            matches = [ { alsa.card_name = "HDA Intel PCH" } ]
            actions = {
                update-props = {
                    api.alsa.use-acp = true
                    device.profile-set = "multiple.conf"
                    device.profile = "multiple"
                    api.acp.auto-profile = false
                    api.acp.auto-port = false
                }
            }
        }
    ]

### High latency with USB DACs (e.g. Schiit DACs)

Changing sample rates or formats might help reduce latency with some DACs such as Schiit Hel 2.[2]

For pipewire-media-session:

Copy the default configuration file `/usr/share/pipewire/media-session.d/alsa-monitor.conf` into `/etc/pipewire/media-session.d/` (or `~/.config/pipewire/media-session.d/`). Then append a new rule-block similar to the following one:

    /etc/pipewire/media-session.d/alsa-monitor.conf (or ~/.config/pipewire/media-session.d/alsa-monitor.conf)

    ...
    rules = {
        ...
        {
            matches = [
                {
                    node.name = "alsa_output.name-of-node"
                }
            ]
            actions = {
                update-props = {
                    audio.format = "S24_3LE"
                    audio.rate = 96000
                    # Following value should be doubled until audio does not cut out or other issues stop occurring
                    api.alsa.period-size = 128
    ...

For wireplumber:

    /etc/wireplumber/wireplumber.conf.d/update-rate-and-format.conf (or ~/.config/wireplumber/wireplumber.conf.d/update-rate-and-format.conf)

    monitor.alsa.rules = [
      {
        matches = [
          {
            node.name = "alsa_output.name-of-node"
          }
        ]
        actions = {
          update-props = {
            audio.format = "S24_3LE"
            audio.rate = 96000
            # Following value should be doubled until audio does not cut out or other issues stop occurring
            api.alsa.period-size = 128
          }
        }
      }
    ]

`alsa_output.name-of-node` node can be obtained using `pw-top`.

Your DAC might support a different format or sample rate. You can check what your DAC supports by querying ALSA:

First get the card number of your DAC:

    $ aplay -l

    ...
    card 3: S2 [Schiit Hel 2], device 0: USB Audio [USB Audio]
      Subdevices: 0/1
      Subdevice #0: subdevice #0
    ...

So in this example it would be card 3. Get all supported sample rates and formats:

    $ cat /proc/asound/cardX/streamX

    ...
    Playback:
      ...
      Interface 1
        Altset 1
        Format: S16_LE
        Channels: 2
        Endpoint: 0x05 (5 OUT) (ASYNC)
        Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
        Data packet interval: 125 us
        Bits: 16
        ...
      Interface 1
        Altset 2
        Format: S24_3LE
        Channels: 2
        Endpoint: 0x05 (5 OUT) (ASYNC)
        Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
        Data packet interval: 125 us
        Bits: 24
        ...
      Interface 1
        Altset 3
        Format: S32_LE
        Channels: 2
        Endpoint: 0x05 (5 OUT) (ASYNC)
        Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
        Data packet interval: 125 us
        Bits: 32
        ...
    ...

In this case `S16_LE, S24_3LE, S32_LE` are the supported formats and `44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000` are the supported sample rates across all formats.

### No sound from USB DAC until 30% volume

Some USB DACs will have no sound output until a certain level of volume is reached [3]. Typically, this is around 15% to 30%, which may result in an uncomfortably loud initial volume and the inability to maintain a low volume. The solution is to ignore hardware mixer volume control by setting `api.alsa.soft-mixer` for the device to `true`.

To achieve this with wireplumber, use:

    /etc/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf (or ~/.config/wireplumber/wireplumber.conf.d/alsa-soft-mixer.conf)

    monitor.alsa.rules = [
      {
        matches = [
          {
            device.name = "alsa_card.name-of-device"
          }
        ]
        actions = {
          update-props = {
            # Do not use the hardware mixer for volume control. It
            # will only use software volume. The mixer is still used
            # to mute unused paths based on the selected port.
            api.alsa.soft-mixer = true
          }
        }
      }
    ]

Refer to WirePlumber#Obtain interface name for rules matching to find the correct value to replace `"alsa_card.name-of-device"`.

Alternatively, you may specify `"~alsa_card.*"` to apply the rules to all your audio devices.

Then, restart pipewire, e.g. by running `systemctl --user restart pipewire`. Set your master volume in `alsamixer`, then save the settings by running `alsactl store` as root. You should now be able to use your volume mixer as normal.

### Realtime audio does not work

If `RTKit error: org.freedesktop.DBus.Error.AccessDenied` shows up in the status of the `pipewire.service` user unit, then the priority of the pipewire daemon was not changed to realtime. See [4] for this issue.

### External sound card not activated after reconnect

Check `~/.config/pipewire/media-session.d/default-profile` if there is any entry with default profile "off" and remove it. If that does not help, remove all files from `~/.config/pipewire/media-session.d/` and restart the `pipewire.service` user unit.

### No Sound or pactl info shows Failure: Connection refused

It means applications are unable to connect to the PipeWire-Pulse service check if the `pipewire-pulse.service` user unit is running.

If that does not fix it, run `strace -f -o /tmp/pipe.txt pactl info` and pastebin `/tmp/pipe.txt` while seeking help on IRC (#pipewire on OFTC) or the mailing-lists.

### Sound does not automatically switch when connecting a new device

To automatically switch to newly connected devices, create this file:

    /etc/pipewire/pipewire-pulse.conf.d/switch-on-connect.conf (or ~/.config/pipewire/pipewire-pulse.conf.d/switch-on-connect.conf)

    pulse.cmd = [
        { cmd = "load-module" args = "module-switch-on-connect" }
    ]

Then restart the `pipewire-pulse.service` with systemctl --user and check that `module-switch-on-connect` is loaded.

### No sound after connecting to Bluetooth device

As of 2020-12-07, if there is no sound after connecting a Bluetooth device, you might need to switch the default sink and/or move a sink input to the correct sink. Use `pactl list sinks` to list the available sinks and `pactl set-default-sink` to switch the default sink to the Bluetooth device. This can be automated via udev using a script similar to this one.

See this Reddit thread for a discussion of the issue. According to author of the script, the headset profile (HSP) might still have problems.

## Bluetooth

### Low audio quality on Bluetooth

In case Bluetooth playback stutters, check the unit status of the `pipewire.service` user unit for errors similar as below:

    Feb 17 18:23:01 HOST pipewire[249297]: (bluez_input.18:54:CF:04:00:56.a2dp-sink-60) client too slow! rate:512/48000 pos:370688 status:triggered

If they appear, check the currently selected codec using `pactl list sinks` and try changing it by setting `bluez5.codec` to one of `sbc aac ldac aptx aptx_hd`. You can also try mSBC support (fixes mic on Sony 1000XM3, i.e. Headphones WH-1000XM3 and Earbuds WF-1000XM3), and the SBC-XQ codec.

Note Headphones like the WH-1000XM3 refuse to advertise any codecs other than SBC/SBC-XQ if "Sound Quality Mode" is set to "Priority On Stable Connection" instead of "Prioritize Sound Quality" in the companion app.

With wireplumber:

    /etc/wireplumber/wireplumber.conf.d/bluez-config.conf (or ~/.config/wireplumber/wireplumber.conf.d/bluez-config.conf)

    monitor.bluez.properties = {
      bluez5.enable-sbc-xq = true
      bluez5.enable-msbc = true
      bluez5.codecs = [ sbc sbc_xq ]
    }

With pipewire-media-session:

    /etc/pipewire/media-session.d/bluez-monitor.conf (or ~/.config/pipewire/media-session.d/bluez-monitor.conf)

    ...
    properties = {
      ...
      bluez5.enable-msbc = true
      bluez5.enable-sbc-xq = true
      bluez5.codecs = [sbc sbc_xq]
    ...

Restart PipeWire by restarting the `pipewire.service` user unit for the changes to take effect.

## Applications

### Terminal bell not working

From PipeWire's perspective, one must have the module x11.bell loaded. This shall be the configuration default (see also in configuration files mentioned above). Check if you have package pipewire-x11-bell installed. Also, your window manager might influence the terminal bell, e.g., for xfwm, check in the xfwm-terminal settings that "Audible bell" is activated. Now, restart pipewire service:

    $ systemctl --user restart pipewire

You can try if the terminal bell works with:

    $ echo $'\a'

### OBS (etc.) display nothing, even if they ask for a window/screen

If you are sure that you have xdg-desktop-portal installed as well as either xdg-desktop-portal-gtk or xdg-desktop-portal-kde, check the running state of the daemons.

In OBS, if everything is working, you should see this in `stdout`:

    ...
    info: [pipewire] desktop selected, setting up screencast
    info: [pipewire] created stream 0x5632d7456850
    info: [pipewire] playing stream…

For multi-monitor setups the slurp package will allow to capture of all the screens.

### FMOD games crashing under PipeWire

Some games that use an old version of the FMOD audio engine, like Pillars of Eternity, invoke `pulseaudio --check` and crash if the PulseAudio binary is not present. A workaround is to symlink `/bin/pulseaudio` to `/bin/true`.[5]

    # ln -s /bin/true /bin/pulseaudio

Note that if you wish to reinstall PulseAudio, you need to remove the symlink.

### No notification sounds from Discord

This might cause by having the min.quantum too low, try setting it to more than 700. You can make an override for Discord specifically by appending the following rule to the pulse.rules section of pipewire-pulse.conf.

    /etc/pipewire/pipewire-pulse.conf (or ~/.config/pipewire/pipewire-pulse.conf)

    ...
    pulse.rules = [
      ...
        {
            # Discord notification sounds fix
            matches = [ { application.process.binary = "Discord" } ]
            actions = {
                update-props = {
                    pulse.min.quantum      = 1024/48000     # 21ms
                }
            }
        }
    ...

### Audio cutting out when multiple streams start playing

This problem can typically be diagnosed by reading the journal of the `pipewire-pulse.service` user unit and finding lines similar to:

    pipewire-pulse[21740]: pulse-server 0x56009b9d5de0: [Nightly] UNDERFLOW channel:0 offset:370676 underrun:940

According to the official PipeWire troubleshooting guide, to solve this problem for wireplumber:

    /etc/wireplumber/wireplumber.conf.d/alsa-config.conf (or ~/.config/wireplumber/wireplumber.conf.d/alsa-config.conf)

    monitor.alsa.rules = [
      {
        matches = [
          {
            node.name = "~alsa_output.*"
          }
        ]
        actions = {
          update-props = {
            api.alsa.period-size   = 1024
            api.alsa.headroom      = 8192
          }
        }
      }
    ]

With pipewire-media-session:

    /etc/pipewire/media-session.d/alsa-monitor.conf (or ~/.config/pipewire/media-session.d/alsa-monitor.conf

    api.alsa.headroom = 1024

If you experience audio stuttering because of kernel page locking or late scheduling see Gaming#Tweaking kernel parameters for response time consistency.

## Other issues

### Auto-switching is not working

If auto-switching is not working it may be an issue with WirePlumber state. As suggested by this comment you can delete WirePlumber's local state and restart the daemon to see if that helps:

    $ rm -r ~/.local/state/wireplumber/

Then restart the `wireplumber.service` user unit.

### Audio problems after standby

If the sound is missing or otherwise garbled after waking the machine up from sleep, it might help to reinitialize ALSA:

    # alsactl init

### Increasing RLIMIT_MEMLOCK

    Dec 13 11:11:11 HOST pipewire-pulse[99999]: Failed to mlock memory 0x7f4f659d8000 32832: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK

Install realtime-privileges and add your own user to the `realtime` group.

Alternatively, increasing memlock from 64kB to 128kB seems enough to fix this. If you are running `pipewire-pulse` under systemd/User, add:

    username	soft	memlock	64
    username	hard	memlock	128

to `/etc/security/limits.d/username.conf`

### Noticeable audio delay or audible pop/crack when starting playback

This is caused by node suspension when inactive.

With wireplumber, create a new file to overwrite the default configuration:

    /etc/wireplumber/wireplumber.conf.d/disable-suspension.conf (or ~/.config/wireplumber/wireplumber.conf.d/disable-suspension.conf)

    monitor.alsa.rules = [
      {
        matches = [
          {
            # Matches all sources
            node.name = "~alsa_input.*"
          },
          {
            # Matches all sinks
            node.name = "~alsa_output.*"
          }
        ]
        actions = {
          update-props = {
            session.suspend-timeout-seconds = 0
          }
        }
      }
    ]
    # bluetooth devices
    monitor.bluez.rules = [
      {
        matches = [
          {
            # Matches all sources
            node.name = "~bluez_input.*"
          },
          {
            # Matches all sinks
            node.name = "~bluez_output.*"
          }
        ]
        actions = {
          update-props = {
            session.suspend-timeout-seconds = 0
          }
        }
      }
    ]

Restart `pipewire.service` and `wireplumber.service` to apply changes.

Instead of disabling suspension entirely, you can also change the timeout value to the desired number of seconds of delay before source suspension.

Some devices implement their own detection of silence and suspension. For them disabling node suspention alone won't work. It's possible to work around them by adding a small amount of noise, making it so the output never goes fully silent:

    .../disable-suspension.conf

    ...
        session.suspend-timeout-seconds = 0,  # 0 disables suspend
        dither.method = "wannamaker3", # add dither of desired shape
        dither.noise = 2, # add additional bits of noise
    ...

It may be necessary to play with `dither.noise` and `dither.method` parameters to make it so the noise is sufficiently silent and simultaneously loud enough to prevent detection of silence. See PipeWire documentation.

With pipewire-media-session:

Disable this by editing `/etc/pipewire/media-session.d/*-monitor.conf` depending on where the delay occurs and changing property `session.suspend-timeout-seconds` to 0 to disable or experiment with other values and see what works.

Alternatively you can comment out the line `suspend-node` in `/etc/pipewire/media-session.d/media-session.conf`.

Restart both `pipewire.service` and `pipewire-pulse.service` to apply these changes, or alternatively reboot.

### No sound until after first playback attempt

When PipeWire is started using socket activation, some PipeWire-native applications may attempt to play audio before WirePlumber configures the nodes, resulting in an error, for example:

    $ mpv -v /path/to/file

    [ao/pipewire] PipeWire does not have any audio sinks, skipping
    [ao] Failed to initialize audio driver 'pipewire'

    $ journalctl --user -u mpd.service

    output: Failed to play on "PipeWire" (pipewire): no target node available
    exception: Failed to open audio output

As a workaround, you can enable the `pipewire.service` user unit.

Hidden categories:

- Pages or sections flagged with Template:Accuracy
- Pages or sections flagged with Template:Out of date
- Sections flagged with Template:Remove

PipeWire/Troubleshooting
Add topic