ao/pulse: fix ao_drain hang when underrun makes buf_diff negative

[dengzhongyuan365-dev]

With prebuf=0, on underrun read_index overtakes write_index, making
buf_diff negative. Passing it to pa_bytes_to_usec() (uint64_t) overflows
and causes ao_drain() to hang forever via an infinite mp_cond_timedwait().

Fixes: 17651

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-aarch64-pc-windows-msvc
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-aarch64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-i686-w64-mingw32
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-x86_64-pc-windows-msvc
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-x86_64-pc-windows-msvc-pdb
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-x86_64-w64-mingw32

macOS

• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-macos-14-arm
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-macos-15-arm
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-macos-15-intel
• mpv-v0.41.0-dev-g64192b3e2-pr17652-23736978073-macos-26-arm

[dengzhongyuan365-dev]

@Dudemanguy
Thank you for your review. I have revised it according to your suggestions.

[Dudemanguy]

Do you have an easy way to reproduce this problem?

[dengzhongyuan365-dev]

Do you have an easy way to reproduce this problem?
@Dudemanguy
On low-performance machines, it's easier to reproduce a video that's played in a single loop for an extended period, typically 4-10 seconds. Otherwise, it usually takes 10 hours or even a day.

But，the code logic also presents computational problems. If an overflow occurs, it can cause subsequent stuttering, ultimately leading to the mpv freezing.

[dengzhongyuan365-dev]

@Dudemanguy Are there any other concerns?

[Dudemanguy]

Nothing. Someone just needs to find the time to actually verify the bug and the fix.

[dengzhongyuan365-dev]

Nothing. Someone just needs to find the time to actually verify the bug and the fix.

ok,there is

Nothing. Someone just needs to find the time to actually verify the bug and the fix.
Reproducing this is rather complicated, but I have a detailed stack trace available for reference.
@Dudemanguy

Thread 11 (Thread 1083849.1083884 "core"):
#0 __futex_abstimed_wait_common64 (private=, cancel=true, abstime=0x0, op=, expected=, futex_word=0x7fff90b56248) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fff90b56248, expected=0, clockid=, abstime=abstime@entry=0x0, private=, cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#2 0x00007ffff008e140 in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x7fff90b56248, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007ffff0091228 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7fff90b56200, cond=0x7fff90b56228) at ./nptl/pthread_cond_wait.c:426
#4 ___pthread_cond_wait (cond=cond@entry=0x7fff90b56228, mutex=mutex@entry=0x7fff90b56200) at ./nptl/pthread_cond_wait.c:458
#5 0x00007fffeb3f7ef4 in mp_cond_timedwait (timeout=, mutex=, cond=) at ../osdep/threads-posix.h:196
#6 ao_drain (ao=0x7fff680bfd40) at ../audio/out/buffer.c:484
#7 0x00007fffeb46c4a8 in uninit_audio_out (mpctx=mpctx@entry=0x55556f5d45e0) at ../player/audio.c:245
#8 0x00007fffeb498050 in idle_loop (mpctx=mpctx@entry=0x55556f5d45e0) at ../player/playloop.c:1308
#9 0x00007fffeb490ed8 in mp_play_files (mpctx=mpctx@entry=0x55556f5d45e0) at ../player/loadfile.c:1994
#10 0x00007fffeb46f9c8 in core_thread (p=0x55556f5d45e0) at ../player/client.c:609
#11 0x00007ffff0091c58 in start_thread (arg=) at ./nptl/pthread_create.c:444
#12 0x00007ffff010e7ac in __thread_start3 () at ../sysdeps/unix/sysv/linux/loongarch/clone3.S:74

[Dudemanguy]

So I can actually pretty easily reproduce what seems to be the issue here (mpv inexplicably freezing for no apparent reason) by just seeking around. It only happens with pulseaudio so at least it appears the be the problem described. This PR doesn't fix it for me though. I'm not sure if the root cause is correct but it's something to do with pulse. --no-pulse-latency-hacks freezes for me as well (i.e. no behavior change).

[dengzhongyuan365-dev]

@Dudemanguy
Thanks,
From the backtrace on my side, the freeze happens because the core thread gets stuck in ao_drain(), and eventually ends up in an infinite pthread_cond_wait() (since mp_cond_timedwait() degrades to an infinite wait when the computed timeout is extremely large). In other words, ao_drain() is being “driven” into an infinite wait by an abnormal delay value computed by a call to ao_get_delay().

My commit fixes one specific, well-defined root-cause point: when PulseAudio latency hacks are enabled, get_delay_hackfixed() estimates the main-buffer delay using (write_index - read_index). With prebuf=0 and an underrun, read_index can overtake write_index, making the difference negative; passing that into pa_bytes_to_usec() (which takes a uint64_t) overflows into a huge latency value, which in turn pushes ao_drain() into an infinite wait. The PR targets exactly this overflow chain.

You mentioned that it still freezes even with --no-pulse-latency-hacks (i.e. no behavior change). That suggests there is another entry point that can push ao_drain() into the same infinite wait — namely the non-hacks latency path (pa_stream_get_latency / get_delay_pulse) still returning abnormal/unavailable latency around seek/underrun. My PR does not cover that path, so it wouldn’t improve your case.

Next, I’ll try to reproduce it using your “seek around repeatedly” scenario and then dig further into the actual root cause: specifically, what PulseAudio returns on the non-hacks path (NODATA? negative flag? extreme values?), and why that causes ao_drain()’s wait to go out of control. Once that’s understood, I’ll propose a targeted fix (rather than just papering over the hang with clamps/timeouts).