[vlc-devel] [RFC] Android OpenSL ES audio output

[Dominique Martinet]

Rémi Denis-Courmont wrote on Fri, Jun 03, 2011 :
> In fact, I would very much like to remove that,
> aout_instance_t.output.i_nb_samples. Most if not all audio outputs can cope
> with arbitrary-sized buffers, as they will anyway copy samples _again_ from
> the VLC mixed buffers into the hardware buffers. Thus, this resizing of
> audio buffers just adds one extra memory and extra latency into the audio
> pipeline. The net effect is an increase the likelihood of hardware output
> under-runs.

Ah. sorry for the delay, I misread what you said up till now.

My problem is not guessing/setting the size of the buffer (OpenSL ES can
indeed handle arbitrary sized buffers), but the number of buffers that
can/will be queued ahead (i.e. if you know i_nb_samples, that would be
how early are buffers given to play)
I am leaving the limit to 42 at the moment, since it needs to be set to
_something_ (internally for OpenSL ES, even if I change the array to a
list), and the limit looks like it is never reached with the current
i_nb_samples (2048, another magic number by the way)
I also added a delay before retrying to enqueue if this ever happens, so
it shouldn't be too bad if it does. the delay size might use getting
changed as well, it could probably be much bigger than what I used
("msleep(CLOCK_FREQ)")

Anyway, no other immediate change planned unless something I just said
bugs anyone.

Regards,
-- 
Asmadeus | Dominique Martinet