diff options
author | wm4 <wm4@nowhere> | 2020-02-13 01:28:59 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-02-13 01:32:58 +0100 |
commit | 5bf433b16f35234a04b8350634c471912fa80343 (patch) | |
tree | d2c5d3fc8b089cf53fe84c42c64f2dc555c27315 /audio/out/push.c | |
parent | f3c498c7f10dea395ee098a4d1d7e2f9602e2a99 (diff) | |
download | mpv-5bf433b16f35234a04b8350634c471912fa80343.tar.bz2 mpv-5bf433b16f35234a04b8350634c471912fa80343.tar.xz |
player: consider audio buffer if AO driver does not report underruns
AOs can report audio underruns, but only ao_alsa and ao_sdl (???)
currently do so. If the AO was marked as not reporting it, the cache
state was used to determine whether playback was interrupted due to slow
input.
This caused problems in some cases, such as video with very low video
frame rate: when a new frame is displayed, a new frame has to be
decoded, and since there it's so much further into the file (long frame
durations), the cache gets into an underrun state for a short moment,
even though both audio and video are playing fine. Enlarging the audio
buffer didn't help.
Fix this by making all AOs report underruns. If the AO driver does not
report underruns, fall back to using the buffer state.
pull.c behavior is slightly changed. Pull AOs are normally intended to
be used by pseudo-realtime audio APIs that fetch an audio buffer from
the API user via callback. I think it makes no sense to consider a
buffer underflow not an underrun in any situation, since we return
silence to the reader. (OK, maybe the reader could check the return
value? But let's not go there as long as there's no implementation.)
Remove the flag from ao_sdl.c, since it just worked via the generic
mechanism. Make the redundant underrun message verbose only.
push.c seems to log a redundant underflow message when resuming (because
somehow ao_play_data() is called when there's still no new data in the
buffer). But since ao_alsa does its own underrun reporting, and I only
use ao_alsa, I don't really care.
Also in all my tests, there seemed to be a rather high delay until the
underflow was logged (with audio only). I have no idea why this happened
and didn't try to debug this, but there's probably something wrong
somewhere.
This commit may cause random regressions.
See: #7440
Diffstat (limited to 'audio/out/push.c')
-rw-r--r-- | audio/out/push.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/audio/out/push.c b/audio/out/push.c index 470f521c68..92fd53631b 100644 --- a/audio/out/push.c +++ b/audio/out/push.c @@ -347,6 +347,8 @@ static void ao_play_data(struct ao *ao) !(flags & AOPLAY_FINAL_CHUNK); if (more) ao->wakeup_cb(ao->wakeup_ctx); // request more data + if (!samples && space && !ao->driver->reports_underruns && p->still_playing) + ao_underrun_event(ao); MP_TRACE(ao, "in=%d flags=%d space=%d r=%d wa/pl=%d/%d needed=%d more=%d\n", max, flags, space, r, p->wait_on_ao, p->still_playing, needed, more); } |