summaryrefslogtreecommitdiffstats
path: root/audio/out/internal.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-13 01:28:59 +0100
committerwm4 <wm4@nowhere>2020-02-13 01:32:58 +0100
commit5bf433b16f35234a04b8350634c471912fa80343 (patch)
treed2c5d3fc8b089cf53fe84c42c64f2dc555c27315 /audio/out/internal.h
parentf3c498c7f10dea395ee098a4d1d7e2f9602e2a99 (diff)
downloadmpv-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/internal.h')
-rw-r--r--audio/out/internal.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/audio/out/internal.h b/audio/out/internal.h
index 7d1d744991..7bdd17ad8a 100644
--- a/audio/out/internal.h
+++ b/audio/out/internal.h
@@ -138,6 +138,8 @@ struct ao_driver {
// Do not set this to true if underruns may be missed in some way. If the
// AO can't guarantee to play silence after underruns, it may be better not
// to set this.
+ // If not set, the generic buffer code will report an underrun if the buffer
+ // becomes empty.
bool reports_underruns;
// Init the device using ao->format/ao->channels/ao->samplerate. If the
// device doesn't accept these parameters, you can attempt to negotiate