[vlc-devel] [PATCH] opensles: protect buffer array with a spinlock

Dominique Martinet asmadeus at codewreck.org
Sat Jan 21 19:14:09 CET 2012

Rafaël Carré wrote on Sat, Jan 21, 2012 :
> > By the way, I just noticed that there was a number of tries added for
> > when we get a buffer_insufficient error, I don't know if we really want
> > that one - did you have many "buffer insufficient" errors in your logs?
> > By that I mean before your patch :-)
> > (it should be ok anyway since there is no break, it should print an
> > "error 7 dropping buffer" message and free it.. actually we probably
> > want it if playback is too slow for cpu reasons)
> Not sure what this error recovery does here, I added the number of tries
> to make sure it doesn't loop forever.

Well, according to the documentation I read, we only get an
SL_RESULT_BUFFER_INSUFFICIENT if the buffer queue is full, so if we do
get it we wait and try to append it again.
It's the same as manually checking that i_toappend_buffer <
i_toclean_buffer, and if it's equal waiting till it isn't to actually
write there and enqueue - if we do this I think we shouldn't get this
error anymore at all.

My real problem is to decide why the buffer queue gets full:
 - Is the system too slow to play and lagging behind, thus gradually
 filling the queue? (we'd want to drop some buffers to catch up)
 - Is the playback rate set too slow, so opensles doesn't empty the
 queue as fast as we try to stack stuff in? (could the rates be just a
 tiny wheeny bit different and lead to slowly filling/starving the
 queue? if there's a major difference, I suppose it should be audible
 and fixable)
 - Is the queue just too small given the buffer size/playrate/whatever?
 (we can try different sizes or find a way to choose what size we need
 at initialization time, but in that case we'd want to wait a bit and
 try to queue again as many times as we would need to; or compute a
 proper waiting time based on whatever timestamp information we can have;
 or check before trying to enqueue and wait at this time)

I'm not really knowledgable about this, so if you have some good idea
there it's all welcome :)

Dominique Martinet | Asmadeus

More information about the vlc-devel mailing list