[MPlayer-users] help needed, mplayer repeats audio frames at the end of video

[Reimar Döffinger]

On Thu, Dec 11, 2014 at 05:34:29PM -0500, David Bolen wrote:
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On 11.12.2014, at 12:35, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> >> On 11 December 2014 11:34:08 CET, Shahid Mahmood Satti <ss at opticom.de> wrote:
> >>> 
> >>> AO: [dsound] 44100Hz 2ch s16le (2 bytes per sample)
> >> 
> >> Not sure which will be available in your build, but could you try other -ao ?
> >> E.g. win32, sdl and openal are available on Windows in principle.
> >> Even though dsound (the one your are using) is generally recommended.
> >
> > I looked at the code and it is indeed a bug.
> > It happens only with dsound due to the API being a bit special.
> > It will probably take a bit to fix, so you might want to use one of the others I mentioned as a work-around.
> 
> I ran into this myself a long time back - I believe in addition to audio
> shorter than video it can happen with extremely short audio files, like <1s
> sound effects.  I had switched to and been using ao_win32 for a long time.
> But I had to start using ao_dsound last year for application reasons, and
> developed a patch that resolved the issue for me, though it's a little
> crude.
> 
> It essentially back-fills the audio buffer with silence, so that any
> overruns at the end are silent rather than garbage audio from what happens
> to be in the buffer.  It also wakes up a little more frequently to help
> minimize the overrun (with no real measurable increase in CPU usage in my
> testing).  I've had it in production use for the past 18 months or so
> without an issue.
> 
> The patch is against a pretty ancient version (r29004) since that's still
> my base, but at least as of last year when working on the patch it didn't
> look like anything had changed in ao_dsound that would be incompatible.

Your patch only works for any looping after the AO uninit was called, which
seems to happen with very few drivers only as nobody has reported that
yet (which drivers do you use?).
The issue here is that it will loop for as much time as the video is
longer than audio, which in theory could be hours.
As for your patch, calling IDirectSoundBuffer_GetStatus is pointless
after your changes as you always use DSBPLAY_LOOPING flag, so it
should always report as playing.
Also a easier "solution" might be to just not loop at all but use
a fixed "usec_sleep(get_delay() * 1000 * 1000);" instead, possibly
with a tiny bit of 0 padding.