Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSL ES: Call processBufferCallback before setting the playstate to playing #1570

Merged
merged 4 commits into from
Jul 12, 2022

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