[vlc-devel] [PATCH] android: Change the buffer length for opensles

[Rémi Denis-Courmont]

On Tue, 28 Feb 2012 23:49:41 +0100, Dominique Martinet
<asmadeus at codewreck.org> wrote:
> Hi,
> 
> Rémi Denis-Courmont wrote on Tue, Feb 28, 2012 :
>> Since blocks are not empty, there cannot be more than
>>    AOUT_MAX_ADVANCE_TIME * maximum sample rate
>>  * minimum sample per block / CLOCK_FREQ
>>  <= 576000 decoded blocks in the pipeline at a time.
>> 
>> That's a lot though.
> 
> I don't know how opensles handles its own queue,

Eh? How is that related? When a buffer is queued to OpenSL, it is freed
from VLC, isn't it?

> but it's too much alright.

I don't understand why you insist on counting blocks.

You can count samples or duration if you want to enforce a maximum.

> Since opensles needs a maximum size anyway, we just need to wait a
> proper time when the current queue is full.

The hardware and its API enforce a maximum buffer size. VLC only needs to
contain the drift between intended and actual PTS. Normally, resampling
avoids excessive drift. Flushing can be used as a last resort.

> Can we assume things like all (most) buffers are of same length?

Not unless you packetize the blocks manually.

> (I'd like to wait for the time needed to play the first buffer of the
> list,

You should only wait (if at all) when the underlying output buffers are
full.

So long as you don't care for S/PDIF pass-through, prepending zeroes in
the buffer is less prone to stutter than sleeping.

> but that would mean waiting longer than what is needed - therefor
> I want to make sure that the e.g. 127 other samples in the queue put
> together are at least as long as the first one to avoid starving)

I don't follow. This seems neither necessary nor sufficient to avoid
starvation.

> I don't know if I'm clear, but I just don't know how long it would be
> smart to wait.

It is smart to wait only when the buffers are full, not when starting up.

ALSA waits at startup only if prepending zeroes fails (installing a
one-shot timer, and thus a dedicated thread, only for startup would be
silly IMHO). OTOH PulseAudio always inserts a timer into the libpulse main
loop.

> Just properly checking that the queue isn't full before queueing
> (instead of checking the queue function's return code)

Again, you should only check the fill level of the underlying buffer and
the timings.

> and waiting a bit
> more than CLOCK_FREQ should help though
> (minimum_sample_per_block*CLOCK_FREQ?)

One second?! You should never ever wait for an arbitrary amount of time in
an audio output.

To postpone playback startup, either prepend zeroes or sleep until
first_PTS - playback_latency.

To wait for space in the output buffer, use the audio hardware interrupt
or, by default, for the duration of a period.

-- 
Rémi Denis-Courmont
http://www.remlab.net/