Heavy stutter in audio playback when using ao=pipewire and pipewire 1.4.3 if sample rate is other than 44100 Hz

[myrslint]

mpv Information

mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on May 21 2025 20:53:16
libplacebo version: v7.351.0
FFmpeg version: n7.1.1
FFmpeg library versions:
   libavcodec      61.19.101
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

(It says -dirty because the official Arch PKGBUILD currently applies https://github.com/mpv-player/mpv/pull/16140 on top of 0.40.0)

Other Information

- Linux version: Arch Linux
- Kernel Version: 6.14.7-arch2-1
- GPU Model: GeForce GTX 1060 6GB
- Mesa/GPU Driver Version: NVIDIA proprietary beta driver 575.51.02 from AUR
- Window Manager and Version: sway version 1.11-rc2-5cfcd1c7 (May 21 2025, branch 'master') / wlroots version 0.20.0.r7491.170f7e070-1
- Source of mpv: `mpv` package from Arch Linux, also tried `mpv-git` from AUR to build tip of the tree
- Latest known working version: N/A, the same version was working fine with pipewire 1.4.2
- Issue started after the following happened: pipewire 1.4.3 packages landed in Arch Linux testing repositories

Reproduction Steps

Play any file with audio sample rate other than 44100 Hz. Audio stutters heavily. If audio sample rate is 44100 Hz there does not seem to be any issue.

MPD used to and continues to work fine before and after the pipewire minor version upgrade.

Expected Behavior

Audio device is onboard Intel HDA and has been working fine to date with mpv and ao=pipewire.

Actual Behavior

Heavy stutter of audio and extremely choppy video playback to match.

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[llyyr]

Can you attach the output if you set PIPEWIRE_DEBUG=5 env variable before starting mpv?

MPD used to and continues to work fine before and after the pipewire minor version upgrade.

mpd doesn't use pipewire, it uses emulated pulse by pipewire. mpv can do the same with ao=pulse.

[HanabishiRecca]

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4713

[myrslint]

Can you attach the output if you set PIPEWIRE_DEBUG=5 env variable before starting mpv?

MPD used to and continues to work fine before and after the pipewire minor version upgrade.

mpd doesn't use pipewire, it uses emulated pulse by pipewire. mpv can do the same with ao=pulse.

While I'm not aware of its internals, on the surface it seems MPD links to libpipewire and the output I have chosen in its configuration file is pipewire without any mention of pulse. I believe if I had chosen pulse (or ALSA or JACK) in the configuration it would then use pipewire's emulation of pulse (or ALSA or JACK).

Below is output.txt from the same commad line as before with env PIPEWIRE_DEBUG=5 prepended and 2>pipewire-debug.txt appended:
output.txt
pipewire-debug.txt

[casta]

Can you attach the output if you set PIPEWIRE_DEBUG=5 env variable before starting mpv?

MPD used to and continues to work fine before and after the pipewire minor version upgrade.

mpd doesn't use pipewire, it uses emulated pulse by pipewire. mpv can do the same with ao=pulse.

Indeed, using ao=pulse instead of ao=pipewire workarounds the issue for mpv.

[myrslint]

Can you attach the output if you set PIPEWIRE_DEBUG=5 env variable before starting mpv?

MPD used to and continues to work fine before and after the pipewire minor version upgrade.

mpd doesn't use pipewire, it uses emulated pulse by pipewire. mpv can do the same with ao=pulse.

Indeed, using ao=pulse instead of ao=pipewire workarounds the issue for mpv.

That does not mean MPD is not using pipewire directly when instructed to do so. It means mpv and MPD are using pipewire in different ways of which the former triggers this problem and the latter does not. Here is MPD's pipewire output plugin. No other sound server API is being used when MPD is configured to use pipewire.

Changing ao to pulse, jack, or alsa for mpv resolves this issue because all of these are parts of pipewire that incorporate adaptation to the changes to 1.4.3, or implement something more correctly than mpv previously did.

[crumblingstatue]

Mpv requests a minimum buffer size of 0 from spa.

mpv/audio/out/ao_pipewire.c

Line 240 in 1d1535f

SPA_PARAM_BUFFERS_size, SPA_POD_CHOICE_RANGE_Int(

If I increase the minimum to something more "reasonable", like 512, the stuttering disappears.

I'm not sure if mpv could do something smarter here to choose the minimum, since the other audio output backends don't produce this behavior.

[HanabishiRecca]

There is an option to control the buffer: --pipewire-buffer

[llyyr]

on the surface it seems MPD links to libpipewire and the output I have chosen in its configuration file is pipewire without any mention of pulse.

My bad, I didn't realize mpd had added one. In any case, the upstream issue has found the commit the broke it as well so we should wait for upstream fix

[myrslint]

In any case, the upstream issue has found the commit the broke it as well so we should wait for upstream fix

The upstream seems to indicate this is intended behavior i.e., that XRUNs occur if the requesting application chooses too small a default buffer size for too long a latency. They also have provided a suggestion for how to improve the choice of default buffer size.

[myrslint]

There is an option to control the buffer: --pipewire-buffer

Ideally, this should be guessed correctly by mpv itself. The option is probably there for corner cases, not daily usage.

[Dudemanguy]

The default is "native" which means that pipewire itself is supposed to set the buffer.

[myrslint]

The default is "native" which means that pipewire itself is supposed to set the buffer.

The "native" default is a name mpv documentation is attaching to not trying to guess. I could not find any indication in pipewire documentation that it guarantees a sane buffer size regardless of client choice.

Pipewire sets the buffer size in relation to the requested buffer size, minimum and maximum bounds, and the client's advertised latency. Pipewire's @wtay seems to be saying mpv needs to tell pipewire a realistic latency to make pipewire choose a realistic buffer size. Or, mpv can choose to set a lower bound (significantly) higher than zero, to force a less smart decision.

[ALRBP]

Same issue here.
--pipewire-buffer=512 fixes it
Thanks to previous comments.