Skip to content

Conversation

robertwu1
Copy link
Collaborator

Fixes #1567

If processBufferCallback() is called after setPlayState_l(SL_PLAYSTATE_PLAYING), there could be cases where onAudioReady() is called from two threads.

We should not release the lock just for processBufferCallback(), so there is a minor refactor here. processBufferCallback() now returns a bool and that bool is used to determine whether requestStop_l() should be called.

@flamme
Copy link
Collaborator

flamme commented Jun 29, 2022

Do you also need to call requestStop_l in bqCallbackGlue? See

(reinterpret_cast<AudioStreamOpenSLES *>(context))->processBufferCallback(bq);

@robertwu1
Copy link
Collaborator Author

Do you also need to call requestStop_l in bqCallbackGlue? See

(reinterpret_cast<AudioStreamOpenSLES *>(context))->processBufferCallback(bq);

Nice catch!

@robertwu1
Copy link
Collaborator Author

Most recent commit simply caches the buffer depth as we suspect that calling setPlayState_l changes the buffer depth

@robertwu1 robertwu1 requested a review from philburk June 30, 2022 00:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

onAudioReady() is called simultaneously from two threads on OpenSL ES backend
3 participants