diff options
author | wm4 <wm4@nowhere> | 2019-10-11 16:49:08 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-10-11 16:52:45 +0200 |
commit | c6c93499cbed839a624fdd279628488f16826616 (patch) | |
tree | 180e114e4e1c710a6e96204cdb48c2862b90cb65 /options/parse_configfile.h | |
parent | ea4685b233090bb155cfa4ec6bf87f421a553168 (diff) | |
download | mpv-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