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

[Dominique Martinet]

Rémi Denis-Courmont wrote on Wed, Feb 29, 2012 :
> > 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.

I'd love not to, but when you initialize the opensles output queue then
you need a maximum, that's the only thing I want to "count"

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

I'm sorry that wasn't clear, the wait was indeed for the case where the
underlying buffer (that I called opensles queue) is full.

Basically, the timing that currently corresponds to stuttering is
corresponding to when the vlc audio output prints "buffer insufficient",
i.e. when (currently) the enqueue call to opensles returned with a value
saying that its queue is full and we wait "msleep(CLOCK_FREQ)"

I don't know why it makes it stutter, but either is the sleep too long
or the enqueue function has a wait of its own.

If the former, then changing the sleep would help, but does it make
sense to wait less?
If the later, I haven't seen anything hinting toward it, but we do know
beforehand wether the queue is full or not, and it's easy to check.

> > 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 wait for space in the output buffer, use the audio hardware interrupt
> or, by default, for the duration of a period.

Err- is that one second? I thought that'd give the minimum time a block could
be, so apparently closer to what you call a period.
I know that's not an excuse, but I just don't know how stuff works so
I'm bound to try the wrong variables first.


As for the audio hardware interrupt, we do get a callback for when one
buffer is done playing (used to free the buffer), so we could know when
the room is freed, but this function cannot enqueue without making yet
another queue and using more variables in p_sys
(e.g. make a proper list, pre-fill the underlying buffer in Play()
(i.e. enqueue directly if buffer not full, or append to local
bottom-less queue otherwise), and keep the underlying buffer filled in
the callback)

That would indeed remove the need for any sleep, so if you say it's
worth it then why not, but I'm not doing it without a validation for the
concept.


Thanks,
-- 
Asmadeus | Dominique Martinet