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

[Dominique Martinet]

Hi,

Cut a whole lot to answer to everything at once, everything I didn't
quote I agree with and will fix what hasn't been already.

Rémi Denis-Courmont wrote on Wed, Jun 01, 2011 :
> > #define BUFF_QUEUE  42
> 
> Undocumented magic number.
[...]
> >     aout_buffer_t                ** p_buffer_array;
> 
> Fixed-size array would be simpler. Or even linked list (aout_buffer_t has
> ->p_next).
[...]
> >     p_sys->p_buffer_array   = malloc( sizeof( **p_sys->p_buffer_array
> > ) *
> >                                     BUFF_QUEUE );
> sizeof() parameter seems wrong, but see above.
[...]
> >     // configure audio source - this defines the number of samples you
> can enqueue.
> >     SLDataLocator_AndroidSimpleBufferQueue loc_bufq = {
> >         SL_DATALOCATOR_ANDROIDSIMPLEBUFFERQUEUE,
> >         BUFF_QUEUE
> >     };
[...]
> >         p_sys->p_buffer_array[p_sys->i_toappend_buffer] = p_buffer;
> >         if( ++p_sys->i_toappend_buffer == BUFF_QUEUE )
> >             p_sys->i_toappend_buffer = 0;
> 
> You will have some "problems" if toappend_buffer reaches toclean_buffer...

p_buffer_array is actually fixed-size, I just can't code, I'll replace
it with a "aout_buffer_t * p_buffer_array[BUFF_QUEUE]" that should also
hopefully fix the malloc since it's no longer needed. (this doesn't mean
I don't want to think about the list)

the loc_bufq variable (hopefully) ensure that OpenSL ES will refuse to
enqueue further buffers, and the play function will try to enqueue it
again immediately (it might be wise to insert some sleep here, but I did
not take the time to look what time delay is appropriate), so
toappend_buffer will never reach toclean_buffer.

I could change p_buffer_array to a queue, but since the number of
buffers is fixed I figured it couldn't hurt, I was in a mindset to do
something that might work quickly when I wrote this.
The only advantage I see to the linked list is that we can decide the
number of buffers we want to append based on the size of a sample for
example.. but I'm not sure how helpful it is though (it's only the
maximum size and it's only the audio core which decides when to enqueue,
I would need to check how far ahead it actually is but probably not
much)
So if I do that, I could really used suggestions for common values,
especially since I think it's better to have a slightly oversized buffer
than to try to enqueue multiple times until it fits (and this would need
quite more modifications)

Regards,
-- 
Asmadeus | Dominique Martinet