[MPlayer-dev-eng] [PATCH] audio file truncation

[Uoti Urpala]

On Tue, 2006-06-06 at 18:03 +0200, Clemens Ladisch wrote:
> Uoti Urpala wrote:
> > [...] This does raise a question though:
> > if it's OK for the ao to play 0 bytes on this call, how do we
> > distinguish cases where the ao will accept data later (presumably after
> > some sound has played and buffers have emptied), and cases where it will
> > never succeed in playing the remaining bytes (assuming this is a
> > significant possibility)?
> 
> (USB device unplugged, network down, sound server killed, ...)

None of those potential reasons are specific to playing the last
samples, and so aren't really relevant. MPlayer doesn't try to detect
such reasons during playback (unless the ao driver does that internally,
but its chances to communicate any error conditions are limited). If the
ao driver stops accepting data in the middle of playback, the playback
will simply hang until the ao starts accepting data again; this differs
from inability to play a partial chunk of samples at the end, where the
samples should be dropped instead (though any ao should be able to
implement playing them, by padding the samples if nothing else).

> My understanding of the API is that play() guarantees to accept at least
> as much data as indicated by get_space().

I haven't seen such a requirement mentioned anywhere, nor does it match
what the code does (it clearly expects to handle play() accepting less
data). I don't see a reason for making it a hard requirement either.

> Anyway, I think get_space() and/or play() should be extended to return a
> negative value to indicate a fatal error.

I agree that being able to return an error from play() would make sense.
Playback truncation fixes still couldn't rely on either getting an error
or the ao eventually accepting the data unless every ao is checked/fixed
to satisfy that though.