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