Skip to content

GitLab

Last edited by P V
Page history

Troubleshooting

General

If submitting a bug/issue please provide PipeWire version, distribution and the desktop environment. It may also be a good idea to try a nightly or master first as your problem may have been fixed.

Journalctl with:

journalctl -xe | grep pipewire
or
journalctl --user-unit=pipewire --user-unit=pipewire-media-session --user-unit=pipewire-pulse -f
or
journalctl --user -u pipewire --user -u pipewire-media-session --user -u pipewire-pulse -f

pw-cli ls, pactl list and pactl showto list objects.

pactl subscribe to list events as they happen.

pw-cli info <id> to get more info about an object.

pw-dumpcan dump the objects in JSON formats, ready for processing with other JSON query tools like jq. If filing an issue please include this as an attachment.

pw-metadata -n route-settings will also list similar things to pw-dump.

Tools like pw-cat, pw-record, and pw-play are also available. See the man pages.

pw-top will tell you the node, period, rate, and latency.

PipeWire debugging options. Eg:

PIPEWIRE_DEBUG=5 <app> 2>log

Usually debug 4 or 5 should be verbose enough but 6 is also available.

Setting the debugging level too high can cause problems for the systemd journal which can now be disabled with:

PIPEWIRE_LOG_SYSTEMD=false

PipeWire Not Loading

PipeWire has two main directories where it's files are stored. The first /etc/pipewire is where the configuration files are. Check to make sure there are no .pacnew (Arch) or .rpmnew (Fedora) files, if there are move them and overwrite the original. The media-session.d directory also contains the with- files if you have pipewire-alsa, pipewire-jack-audio-connection-kit, and pipewire-pulseaudio installed you should have with-alsa, with-jack, and with-pulseaudio.

The second directory is ~/.config/pipewire which contains four files (unless you've copied your configuration files here) default-nodes, default-profile, default-routes, and restore-stream. It may be that these files need to be deleted because an update breaks something, and this could cause PipeWire from behaving normally.

It could also be that you don't have pipewire-media-session running as it has recently been split into it's own systemd service file. Although it's still possible to execute it from within pipewire.conf. Also make sure that there is only one instance of pipewire-media-session running as it will cause problems as well.

Things to try:

  1. Make sure there are no .new files.
  2. Delete the four files in ~/.config/pipewire/media-session.d.
  3. Delete your configuration files and reinstall the PipeWire packages.
  4. Make sure your systemd services and sockets are enabled and started this includes pipewire.service, pipewire.socket, pipewire-pulse.service, pipewire-pulse.socket and depending on the distribution or if you've built from source you might have pipewire-media-session.service.

Bluetooth

For debugging:

  1. Stop pipewire-media-session.service and wireplumber.service using systemctl, and pkill -f pipewire-media-session; pkill -f wireplumber. Disconnect Bluetooth device.
  2. If you are using PipeWire Media Session (default on Fedora 34), run from command line with:
PIPEWIRE_DEBUG=4 pipewire-media-session 2>&1 | grep --line-buffered -Ei '\[[EW]\]|\[\s*bluez5|\[\s*a2dp|\[\s*backend|\[\s*sco|quirk' > pipewire-bluez.log
  1. If you are using Wireplumber (default on Fedora 35), the command is instead:
WIREPLUMBER_NO_PW_LOG=1 PIPEWIRE_DEBUG=4 wireplumber 2>&1 | grep --line-buffered -Ei '^\[?[EW]\]?|\[\s*bluez5|\[\s*a2dp|\[\s*backend|\[\s*sco|quirk' > pipewire-bluez.log
  1. Connect Bluetooth device, and cause the problem behavior.
  2. Stop PipeWire Media Session / Wireplumber with ctrl-C and attach the produced pipewire-bluez.log to the issue. It contains information of what PipeWire tried to do during the connection.

Also check if dmesg contains messages about missing Bluetooth firmware. There have been issues where the proper firmware was not getting installed for devices like for example the Asus BT400 that uses a Broadcom chipset.

Missing Bluetooth profiles

If a Bluetooth device is missing some profiles (A2DP or HFP/HSP ones are missing, or device does not connect at all), the problem may be in the Linux Bluetooth stack below pipewire (BlueZ, kernel drivers, firmware, hardware). So consider, in order:

  1. Unpair device, pair device again.
  2. Clear BlueZ cache: Delete all files and directories under /var/lib/bluetooth/ and systemctl restart bluetooth. This forgets all devices and you need to pair devices again.
  3. Check BlueZ version. Consider upgrading if possible with your distro. You can see what is the latest version here.

Bluetooth traffic dump

In some cases, a Bluetooth traffic dump may be necessary. It can be taken as follows:

  1. Power off the Bluetooth device (important!)
  2. Run sudo btmon -A -S -w dump.btsnoop
  3. Connect device
  4. Do the problematic operation
  5. Ctrl-C btmon.

Advanced users may inspect the traffic dump by opening it e.g. with wireshark.

Note that the traffic dump contains all BT traffic during the time when the dump was taken, including MAC addresses etc. identifying information.

Crashes

If PipeWire is crashing we require a backtrace to fix it this can be obtained either of two ways:

Attach to the currently running PID:

gdb -p `pidof <program>`
# At the prompt
continue
# Let the program crash
thread apply all backtrace

Or run the program through gdb. In this example pipewire-media-session is crashing you would first have to stop PipeWire with systemctl. Then comment out the line that starts pipewire-media-session in the pipewire.conf file. Restart PipeWire with systemctl. Then start pipewire-media-session with gdb:

gdb pipewire-media-session
# At the prompt
continue
# Let the program crash
thread apply all backtrace

Or if you are a Fedora user you can use this tutorial and use coredumpctl and ABRT to generate coredumps to add to reports.

Memory Leaks

If PipeWire is taking up too much memory you can run it through valgrind, for example. If it's pipewire-pulse that's having the problem either stop it using systemctl or kill it and run it with:

valgrind --trace-children=yes --leak-check=full pipewire-pulse

Then add the output to the report.

My Audio Card Does Not Have XYZ

This could be a problem with the mixer detection code.

Client too slow! rate:64/48000 pos:532930560 status:triggered

Too slow means that it could not provide data in the current cycle. Status:triggered means that the server woke it up but the client has not completed the work and changed the status to finished, it's actually not even awake so the process has not even been scheduled. It goes from not-triggered -> triggered -> awake -> finished.

No Node Found

Is when a stream was playing and then the target node disappeared. Happens when a monitor stream in pavucontrol is destroyed.

Underrun/Underflow and Broken Pipe Errors

Applications not providing data fast enough and not enough headroom in the device to recover. Increase headroom.

Stuttering Audio in Virtual Machine

Please see #469 (comment 768518)

Loud pops when starting a sound

This is likely because of power saving settings. You can try:

echo 0 > /sys/module/snd_hda_intel/parameters/power_save

This setting will last until you reboot. You can make it permanent by adding this text to /etc/modprobe.d/audio_disable_powersave.conf:

options snd_hda_intel power_save=0

Xruns

There are 2 causes of xruns:

  1. Application's can't complete the cycle in time. It can be because the kernel didn't wake them up in time or that they didn't get enough time allocated.
  2. Driver timing are to tight. The driver is not woken up fast enough to keep the buffer filled.

1 can cause 2. 2 can be improved by adding more buffering (increasing headroom). Adding headroom does not improve 1.

With pw-top you can see what causes the xruns. If the application xruns are increasing, it's 1. If it's only the driver increasing xruns, it's 2. If both are increasing it's 1 causing 2.