ao_avfoundation: tail of every file is dropped at EOF (buffered audio never drained)

mpv Information

mpv v0.41.0-1041-gc611c1c6f Copyright © 2000-2026 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.360.1
FFmpeg version: 9.0.1
FFmpeg library versions:
   libavcodec      63.1.101
   libavdevice     63.1.101
   libavfilter     12.1.101
   libavformat     63.1.101
   libavutil       61.1.101
   libswresample   7.1.101
   libswscale      10.1.101

Other Information

- macOS version: macOS 27.0 (26A5425a), Apple Silicon (Mac16,10 / arm64)
- Source of mpv: Homebrew --HEAD build. Also reproduced with the 0.41.0 release bottle.
- Latest known working version: unknown, reproduces on both 0.41.0 release and current git
- Issue started after the following happened: noticed on macOS 27, where #18384 makes
  ao_coreaudio fail and mpv silently falls back to ao_avfoundation

Reproduction Steps

1. Generate a 30 second test tone:

ffmpeg -f lavfi -i "sine=frequency=440:duration=30" -ac 2 -ar 44100 -c:a pcm_s16le stereo30.wav

1. mpv --no-config --ao=avfoundation stereo30.wav
2. Watch the position counter. Playback ends and mpv exits at 00:00:26 / 00:00:30.
3. Control: mpv --no-config --ao=coreaudio stereo30.wav reaches 00:00:29 / 00:00:30.

The shortfall is a constant amount of time, not a proportion of the file:

4.0 seconds every time, which is exactly what ao_avfoundation reports having buffered:

[ao/avfoundation] device buffer: 88200 samples.
[ao/avfoundation] using soft-buffer of 88200 samples.

88200 + 88200 = 176400 samples at 44100 Hz = 4.000 s.

Measuring total process wall time shows audio really is lost, not just mis-reported:

So roughly 1.6 to 1.7 seconds of audio is never played, and the reported position stops about 4 seconds early. In the log, mpv reaches EOF, logs audio draining and draining left over audio, waits about 2 seconds, and exits, without waiting for the AVSampleBufferAudioRenderer to finish playing everything already queued.

Expected Behavior

Playback plays to the end of the file, as ao_coreaudio does.

Actual Behavior

The tail of every file is silently discarded, with no error or warning. On short files this is severe: a 16 second clip loses about 10 percent of its running time off the end.

Relationship to #18384

These look like the same problem from a user's point of view but are separable, so I am filing this rather than adding to that thread.

On macOS 27, #18384 makes ao_coreaudio fail with unable to set the input channel layout on the audio unit ([206][255][255][255]/-50), mpv falls back to ao_avfoundation, and the user sees truncation. That matches the "does not play to completion" half of #18384.

But the truncation reproduces with an explicit --ao=avfoundation on files where ao_coreaudio initialises and plays correctly, including plain stereo files that never trigger the -50 error at all. It also reproduces on the 0.41.0 release. So it is independent of #18384 and will still be there once the channel layout bug is fixed.

Log File

Both logs (produced with --log-file, full and untruncated) are here, since the CLI cannot attach files to an issue:

https://gist.github.com/compupane/aa62a7c7afef8e20597a9c5b71a47c68

• mpv-avfoundation-truncation.txt is the reproduction
• mpv-coreaudio-control.txt is the same file with --ao=coreaudio as a control

Sample Files

No sample needed, the ffmpeg one-liner above generates it. Any audio file reproduces it.

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

• I tested and confirmed that the issue exists with the latest release version or newer.
• 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. (not applicable, no crash)