mpv PipeWire Audio Not Working: How to Fix It

When mpv plays video but produces no sound, selects the wrong output, reports an audio-device error, or behaves differently under PipeWire than another player, the cause is usually one of a few things: an unavailable mpv audio-output driver, a stale device name, a stopped PipeWire service, a broken session manager, an application profile, or sandbox restrictions. Less commonly, the apparent PipeWire problem is actually a missing audio track, unsupported media format, muted stream, network failure, or custom mpv configuration.

The safest approach is to establish whether a clean mpv process can play a known-good local file. From there, test PipeWire's native output and its PulseAudio compatibility layer separately. Stop as soon as a test restores normal sound. Changing unrelated subtitle, HDR, shader, or hardware-decoding settings after audio starts working can create new problems without improving PipeWire.

1. Confirm the Symptom With a Minimal Clean mpv Command

Begin in a terminal so that mpv can display errors. Use a local media file that you know contains a working audio track. Avoid an online URL for this first test because yt-dlp, authentication, DNS, and network conditions introduce unrelated failure points.

On Linux, run:

mpv --no-config --terminal=yes "/path/to/known-good-file.mkv"

On Windows or macOS, the same basic command is useful, although native PipeWire is generally relevant to Linux systems. If mpv on Windows or macOS connects to a remote PipeWire setup, runs inside a Linux virtual machine, or uses a compatibility environment, test the Linux audio service inside that environment. Do not assume a native Windows or macOS audio problem is caused by PipeWire merely because an old configuration contains ao=pipewire.

The --no-config option prevents the normal user configuration and scripts from loading. If sound works during this test, mpv, the file, and at least one default audio route are functional. The likely cause is then inside mpv.conf, a profile, a script, an environment variable, or a device-selection rule. Stop changing operating-system services and inspect the configuration instead.

If the file opens but remains silent, display the track list:

mpv --no-config --track-list "/path/to/known-good-file.mkv"

Confirm that an audio track exists and is selected. During playback, press # using mpv's default bindings to cycle audio tracks. A custom input file can change that binding, which is another reason to begin with --no-config.

1.1 Test Each Relevant Audio Output

Ask the installed mpv build which audio-output drivers it supports:

mpv --ao=help

Look for pipewire and pulse. Their presence depends on how that particular mpv binary was built. Do not assume that every package includes a native PipeWire output merely because PipeWire is installed on the computer.

If pipewire appears, test it explicitly:

mpv --no-config --ao=pipewire "/path/to/known-good-file.mkv"

Then test the PulseAudio-compatible route:

mpv --no-config --ao=pulse "/path/to/known-good-file.mkv"

Many PipeWire desktops provide a PulseAudio-compatible server through pipewire-pulse. Therefore, --ao=pulse can still send audio through PipeWire. If Pulse works but the native PipeWire output does not, use Pulse temporarily and investigate whether the mpv package lacks usable native PipeWire support. If both work, let mpv select automatically unless you have a specific reason to force one.

Success means that the expected audio is audible, playback time advances normally, and the terminal does not report repeated device or connection failures. Once one clean command succeeds, stop modifying system services and compare that command with the normal configuration.

2. Check mpv Options, Profiles, Scripts, and Device Selection

A clean test that works while normal playback fails strongly indicates an mpv configuration issue. Inspect settings individually rather than deleting the entire configuration folder. Back up a file before editing it.

2.1 Inspect Audio Output and Device Rules

Search mpv.conf and included configuration files for options such as:

• ao=pipewire or ao=pulse
• audio-device=...
• audio-exclusive=yes
• audio-channels=...
• audio-spdif=...
• mute=yes or a very low starting volume
• aid=no or an invalid preferred audio-track rule

List the devices visible through the selected audio output:

mpv --no-config --ao=pipewire --audio-device=help

If testing Pulse compatibility, use:

mpv --no-config --ao=pulse --audio-device=help

Device identifiers are backend-specific and may change when hardware, docks, Bluetooth profiles, HDMI displays, or session configuration changes. Do not copy a display label from a desktop mixer and assume it is the exact identifier mpv expects. Use the value reported by mpv for the active output driver.

Test automatic selection before forcing a device:

mpv --no-config --ao=pipewire --audio-device=auto "/path/to/file.mkv"

If automatic selection works, remove or comment out the stale audio-device line. If a specific listed device works, save that exact identifier only after confirming it remains stable across a logout or reboot.

2.2 Check Conditional Profiles

An mpv profile can quietly apply audio settings only to certain files, protocols, displays, or filenames. This explains why local files may work while network streams fail, or why one playlist opens on the wrong output.

Use the following command to inspect a named profile:

mpv --show-profile=PROFILE_NAME

Also review profile sections in mpv.conf, including conditional auto profiles. Search for audio-output, device, track-selection, and passthrough options. Temporarily comment out one suspicious line at a time, then repeat the same known-good test.

2.3 Isolate Input Bindings and Scripts

An input binding can mute audio, cycle tracks, change devices through a script, or load a profile. Scripts may also adjust volume and tracks when files load. Run normal mpv with scripts disabled while retaining other configuration:

mpv --load-scripts=no "/path/to/file.mkv"

If that works, restore scripts selectively. Inspect input.conf for bindings involving mute, volume, audio, aid, profiles, or script messages.

Subtitle settings, screenshots, shaders, HDR options, and hardware decoding do not normally control PipeWire output. However, a failing script or severe video-decoding stall can make the entire player appear broken. Test --hwdec=no only if playback freezes, timestamps do not advance, or the log shows decoder or GPU errors alongside the audio symptom. If video advances normally and only sound is missing, remain focused on audio routing.

3. Verify PipeWire, Pulse Compatibility, and the Session Manager

PipeWire supplies the media service, while a session manager such as WirePlumber handles policy, device discovery, links, defaults, and permissions. A running PipeWire process without a healthy session manager can still produce missing or incorrectly routed devices.

3.1 Check User Services

On Linux systems using systemd user services, inspect the relevant units:

systemctl --user status pipewire pipewire-pulse wireplumber

Some distributions use different service arrangements, so a missing unit name is not automatically proof of failure. Use your distribution's documented service model. For common systemd setups, restart the user services without administrative privileges:

systemctl --user restart pipewire pipewire-pulse wireplumber

Do not run desktop PipeWire user services with sudo. They belong to the logged-in user's session. After restarting, rerun the clean mpv command. Success means mpv creates a playback stream and the stream appears in the desktop sound controls or PipeWire inspection tools.

3.2 Inspect the PipeWire Graph and Defaults

Use PipeWire's command-line tools where available:

wpctl status

The output should show sinks, sources, streams, and a default output. Check volume and mute state:

wpctl get-volume @DEFAULT_AUDIO_SINK@

If necessary, unmute the default sink:

wpctl set-mute @DEFAULT_AUDIO_SINK@ 0

You can also use a trusted desktop mixer to verify that mpv is not muted and that its stream is routed to the desired headphones, speakers, HDMI output, or Bluetooth device. Application streams may retain a previous route even when the system default changes.

If no sinks appear, the problem is broader than mpv. Test another normal audio application. If every application fails, repair the PipeWire session, device profile, or operating-system audio setup before changing mpv. If another player works, compare its selected backend and destination with mpv's explicit --ao

4. Check Sandboxes, Paths, Streams, and Media Limitations

4.1 Flatpak and Other Sandbox Access

A Flatpak build can see different sockets, files, tools, and configuration from a host-installed mpv. Confirm that the application has audio access and can reach the PipeWire or PulseAudio socket provided by the sandbox. Review permissions with:

flatpak info --show-permissions APP_ID

Use the actual application ID. A graphical Flatpak permission manager can also show audio and filesystem access. Avoid granting broad filesystem access unless it is required. Audio access and access to a specific media directory are separate concerns.

Compare the sandboxed build with a distribution package from a trusted repository. If one works and the other does not, do not mix their configuration paths or assume they use the same mpv build options. Success means the sandboxed application can open the intended file and create an audible stream through the permitted audio socket.

4.2 File Paths and Shell Quoting

A badly quoted path can prevent the intended file from opening, especially when it contains spaces, brackets, ampersands, or shell metacharacters. Put the complete path inside quotes. Confirm that mpv reports the expected filename and an audio track before diagnosing the audio server.

For playlists and external audio files, test the main file alone. A playlist entry may point to a missing companion audio file. An external audio track can also be selected instead of the embedded track and then fail to load.

4.3 Online URLs and yt-dlp

For an online URL, first prove that local audio works. Then run the URL from a terminal with a current, trusted yt-dlp installation if the site requires it. mpv may need the executable in its process path, which can differ between a terminal, desktop launcher, and sandbox.

If the URL resolves to separate audio and video streams, a yt-dlp extraction failure may leave no playable audio source. That is not a PipeWire routing failure. Check whether mpv's track list contains audio and whether the log reports URL extraction, HTTP, certificate, authentication, or format-selection errors.

Do not use unofficial codec packs or random binary downloads to solve a network extractor problem. Install mpv, yt-dlp, and supporting tools through trusted operating-system repositories or their official distribution channels.

4.4 Codec and Passthrough Limitations

If most files work but one file does not, inspect that file's audio track. A forced passthrough configuration can fail when the selected device or connection does not accept the encoded format. Test without the regular configuration and without forced digital passthrough. Also try another known-good player to determine whether the media itself is damaged or unsupported.

Success with ordinary decoded PCM audio but failure with passthrough points to the receiver, HDMI route, format negotiation, or passthrough options rather than general PipeWire availability.

5. Use Logs and Runtime Information to Find the Exact Failure

When the basic tests do not explain the mpv player issue, collect one focused log. Avoid changing options while collecting it, because that makes comparisons unreliable.

mpv --no-config --msg-level=ao=trace --log-file=mpv-pipewire.log "/path/to/file.mkv"

Review lines associated with ao, PipeWire, PulseAudio, device selection, track initialization, and audio decoding. Useful distinctions include:

• No supported audio-output driver is available
• The selected device name does not exist
• The backend cannot connect to the user audio server
• An audio track was never selected or initialized
• The decoder cannot handle the file's audio stream
• Playback is paused, muted, or stalled before audio begins

Increase global verbosity only when needed. Extremely noisy logs can hide the first meaningful error. Also inspect the track list and press i during playback to open mpv's default stats overlay. The overlay can confirm the selected audio track, format, channel layout, and whether playback time advances. Custom bindings or scripts may alter the key, so repeat under --no-config when uncertain.

Logs can contain local paths, URLs, query tokens, usernames, and device names. Remove sensitive information before sharing them publicly.

6. Run a Clean Temporary Test Before Making Permanent Changes

Use a small test matrix and change only one variable per run:

1. Play a known-good local file with --no-config.
2. Test automatic audio-output selection.
3. Test --ao=pipewire if listed by --ao=help.
4. Test --ao=pulse through PipeWire's PulseAudio compatibility service.
5. Test --audio-device=auto.
6. Confirm the PipeWire session manager and default sink are healthy.
7. Run normal configuration without scripts.
8. Restore profiles, scripts, device rules, and special media sources one at a time.

Keep the first successful command as your baseline. For example, if mpv --no-config --ao=pulse file.mkv works, the immediate practical fix may be to use ao=pulse while determining why native PipeWire output fails. Because pipewire-pulse routes PulseAudio clients into PipeWire, this is a valid PipeWire desktop configuration, not necessarily a fallback to the old PulseAudio server.

Do not permanently force an output until you understand why automatic selection failed. Automatic selection is often more resilient when switching between built-in speakers, USB interfaces, Bluetooth devices, docks, and HDMI displays.

7. Quick Fix Checklist

• Test a known-good local file with mpv --no-config.
• Run mpv --ao=help before assuming native PipeWire support exists.
• Compare --ao=pipewire with --ao=pulse.
• Remove stale audio-device values and test audio-device=auto.
• Confirm an audio track exists and is selected.
• Check pipewire, pipewire-pulse, and the session manager.
• Use wpctl status to verify the default sink, mute state, and route.
• Check Flatpak audio and file permissions when mpv is sandboxed.
• Disable scripts temporarily instead of deleting the configuration folder.
• For URLs, separate yt-dlp or network errors from real audio-output failures.
• Capture a focused log with --msg-level=ao=trace.
• Stop changing settings as soon as a repeatable clean test succeeds.

8. Frequently Asked Questions

8.1 Does ao=pulse Mean mpv Is Not Using PipeWire?

Not necessarily. On many Linux desktops, pipewire-pulse implements the PulseAudio-compatible server. An application using --ao=pulse can therefore send its audio into PipeWire. Check the running user services and wpctl status to confirm the actual server and stream.

8.2 Why Is pipewire Missing From mpv --ao=help?

The installed mpv binary may have been built without native PipeWire audio-output support. Use a trusted package that includes the desired feature, or use --ao=pulse with PipeWire's PulseAudio compatibility layer. Do not download an unknown replacement binary solely to gain one output driver.

8.3 Why Does mpv Work With --no-config but Fail Normally?

A configuration option, profile, script, input binding, or saved device name is interfering. Compare the successful clean command with mpv.conf, disable scripts temporarily, and inspect conditional profiles. Change one line at a time.

8.4 Why Does Another Player Have Sound While mpv Does Not?

The players may use different backends, devices, track-selection rules, sandbox permissions, or passthrough settings. Check which --ao option succeeds in mpv and whether mpv selected the correct track. Another player working proves that the hardware can produce audio, but it does not prove that mpv can access the same route.

8.5 Can Hardware Decoding Cause a PipeWire Audio Failure?

Hardware decoding does not normally choose the audio backend. However, a GPU or display-server failure can stall playback so that audio never advances normally. Test --hwdec=no only when the video freezes, timestamps stall, or logs show related GPU errors. For normal moving video with silence, investigate tracks and audio output first.

8.6 When Should I Stop Troubleshooting?

Stop when the same known-good file plays repeatedly with audible sound, the correct track and device are selected, and no recurring backend errors appear. Preserve that command as a baseline. Add custom profiles, scripts, shaders, network sources, and device rules back individually so that any regression has a clear cause.