mirror of
https://github.com/mpv-player/mpv.git
synced 2024-09-20 03:52:22 +02:00
baa7b5c8dd
I feel like this makes slightly more sense. At least it doesn't include the potentially arbitrary constant latency that is generally included in the delay value. Also, the buffer status doesn't matter - either we've filled the entire buffer (then we can wait this long), or there's not enough data anyway (then the core will wake up the thread if new data is available). But ultimately, we have to guess, unless the AO does notify us with ao_wakeup_playthread(). Draining may now wait for no reason up to 1/4th of the total buffer time. Shouldn't be a disimprovement in practice. |
||
|---|---|---|
| .. | ||
| ao_alsa.c | ||
| ao_audiotrack.c | ||
| ao_audiounit.m | ||
| ao_coreaudio_chmap.c | ||
| ao_coreaudio_chmap.h | ||
| ao_coreaudio_exclusive.c | ||
| ao_coreaudio_properties.c | ||
| ao_coreaudio_properties.h | ||
| ao_coreaudio_utils.c | ||
| ao_coreaudio_utils.h | ||
| ao_coreaudio.c | ||
| ao_jack.c | ||
| ao_lavc.c | ||
| ao_null.c | ||
| ao_openal.c | ||
| ao_opensles.c | ||
| ao_pcm.c | ||
| ao_pulse.c | ||
| ao_sdl.c | ||
| ao_wasapi_changenotify.c | ||
| ao_wasapi_utils.c | ||
| ao_wasapi.c | ||
| ao_wasapi.h | ||
| ao.c | ||
| ao.h | ||
| buffer.c | ||
| internal.h | ||