[vlc-devel] [PATCH] android: Change the buffer length for opensles
remi at remlab.net
Wed Feb 29 09:04:29 CET 2012
On Tue, 28 Feb 2012 23:49:41 +0100, Dominique Martinet
<asmadeus at codewreck.org> wrote:
> 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
You should only wait (if at all) when the underlying output buffers are
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
> 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
> 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
> and waiting a bit
> more than CLOCK_FREQ should help though
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.
More information about the vlc-devel