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

[Clemens Ladisch]

Uoti Urpala wrote:
> 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.

I just wanted to illustrate that there actually is a significant
possibility of play() never succeeding.

> > 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).

Sorry, I wasn't very clear.  play() guarantees that the _exact_ amount
returned by get_space() can be accepted.  play() can accept less data
than its 'len' parameter only if 'len' is not equal to the return value
of get_space(); in other words, get_space() rounds its return value
according to the requirements of play().

This means that the truncation problem could be solved^H^H^H^H^H^Hworked
around by padding the last output to the size last returned by
get_space().

A better solution would be if the driver would communicate to its users
what its internal alignment requirements are.  Apparently,
ao_data.outburst seems to be such a value, but it is ignored by
mplayer.c when playing a video, and not all drivers bother to set it.


Regards,
Clemens

-- 
http://www.fastmail.fm - And now for something completely different