OpenSL Streaming falls behind unless touching the screen

40 views
Skip to first unread message

Halsafar

unread,
Apr 11, 2014, 8:03:30 PM4/11/14
to andro...@googlegroups.com
This is going to be a tough one to explain.

I am using OpenSL, streaming at the native device sample rate and buffer size as reported by the new API calls.  The OpenSL callback thread does nothing except atomically decrement an integer and signals a condition var.  Another thread is enqueue`n buffers and atomically increasing that integer or blocking on that condition var.  So the OpenSL audio thread is doing very little and never blocks.  The other thread in this case is really just the main thread spitting out buffer sized samples as often as it can, so yes this can block the main thread.

The problem...  So all works very well except that I notice the stream starts to lag a few seconds into playing, I notice the main thread begins to lock a ton.  This all clears up if I touch the screen, as long as I keep moving my fingers on the the screen the audio plays perfectly, the main thread almost never locks.

This makes no sense to me as my previous problems with touching the screen involved it slowing down frame rate heavily.  I am seeing the opposite here.

What is going on here?  I assume the problem is entirely related to the threading going on.  It might be that by spamming the main thread with input events it is taking a bit longer and allowing the audio thread the time to catch up before causing the main thread to block.  So I did try and disabling blocking and now I get lots of audio artifacts unless I start touching the screen.  The audio artifacts in the case of not blocking come from simply discarding the produced samples, so they are expected.

The app is just a blank Native Activity, compiled with NDK.  

Tested on Samsung Galaxy S4 and LG Optimus G.





Halsafar

unread,
Apr 11, 2014, 8:06:24 PM4/11/14
to andro...@googlegroups.com
I should add that the integer being atomically decremented and incremented represents the number of free buffers.  So when there are none free the audio sample producing thread will block which in this case is the main thread.  
Reply all
Reply to author
Forward
0 new messages