summaryrefslogtreecommitdiffstats
path: root/options/parse_configfile.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-10-11 16:49:08 +0200
committerwm4 <wm4@nowhere>2019-10-11 16:52:45 +0200
commitc6c93499cbed839a624fdd279628488f16826616 (patch)
tree180e114e4e1c710a6e96204cdb48c2862b90cb65 /options/parse_configfile.h
parentea4685b233090bb155cfa4ec6bf87f421a553168 (diff)
downloadmpv-c6c93499cbed839a624fdd279628488f16826616.tar.bz2
mpv-c6c93499cbed839a624fdd279628488f16826616.tar.xz
ao_alsa: mess with underrun handling again
This commit tries to prepare for better underrun reporting. The goal is to report underruns relatively immediately. Until now, this happened only when play() was called. Change this, and abuse that get_delay() is called "relatively often" - this reports the underrun immediately in practice. Background: In commit 81e51a15f7e1 (and also e38b0b245ed4), we were quite confused about ALSA underrun handling. The commit message showed uncertainty how case 3 happened, but it's blindingly obvious and simple. Actually reading the code shows that ALSA does not have a concept of a "final chunk" (or we don't use it). It's obvious we never pass the AOPLAY_FINAL_CHUNK flag along to the ALSA API in any way. The only thing we do is simply writing a partial fragment. Of course this will cause an underrun. Doing a partial write saves us the trouble to pad the last frame with silence, or so. The main reason why the underrun message was avoided was that play() was never called with a non-0 sample count again (except if reset() was called before that). That was OK, at least the goal of avoiding the unwanted message was reached. (And the original "bogus" message at end of playback was perfectly correct, as far as ALSA goes.) If network stalls, play() will called again only once new data is available. Obviously, this could take a long time, thus it's too late.
Diffstat (limited to 'options/parse_configfile.h')
0 files changed, 0 insertions, 0 deletions