Re: SLAndroidSimpleBufferQueue and buffer lifetime

125 views
Skip to first unread message

Glenn Kasten

unread,
Jul 16, 2012, 11:50:24 AM7/16/12
to andro...@googlegroups.com
OpenSL ES buffers are owned by the application, so there's no reason why you shouldn't be able to free them from a callback completion handler. [It's an unusual place to do it, but it should work.] Suggestions: get a stack trace with line numbers at SIGSEGV. Also try simplifying the program until the SIGSEGV goes away; often the last thing removed will provide a hint as to where the problem may be. 

On Friday, July 13, 2012 3:53:47 PM UTC-7, Glennward Turtle wrote:
I have an implementation on top of OpenSL that will queue up to 32 buffers and delete them within the callback on the assumption that they are no longer needed by Android.  However, I experience SIGSEGV when shutting down the engine and all related objects.  Yes, I have cleared the buffer via the Clear() method.  Might this be the source of my trouble?

Ardy

unread,
Jul 23, 2012, 3:06:53 PM7/23/12
to andro...@googlegroups.com
If you look at the code for OpenSL, it just copies the buffer you hand it to the audio track buffer and then invokes your callback. Once it has handed it to you, you should be free to delete it without any worries.

Glenn Kasten

unread,
Jul 24, 2012, 11:52:47 AM7/24/12
to andro...@googlegroups.com
At the risk of being too pedantic, the copy can happen any time between when you call Enqueue and when your callback is called. This means it is unsafe to re-use the buffer right after Enqueue returns -- you must wait until your callback is called.  The implementation might copy inside of Enqueue in some cases, but don't rely on that.

If you don't use callbacks, you can determine when the copy happens by polling the GetSTate count and play index. But I recommend the callback approach.
Reply all
Reply to author
Forward
0 new messages