Skip to content

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

Merged
robertwu1 merged 4 commits intomainfrom
robertwu/processDataCallbackBefore
Jul 12, 2022
Merged

OpenSL ES: Call processBufferCallback before setting the playstate to playing#1570
robertwu1 merged 4 commits intomainfrom
robertwu/processDataCallbackBefore

Conversation

@robertwu1
Copy link
Copy Markdown
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.

Comment thread src/opensles/AudioOutputStreamOpenSLES.cpp
@flamme
Copy link
Copy Markdown
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
Copy Markdown
Collaborator Author

Do you also need to call requestStop_l in bqCallbackGlue? See

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

Nice catch!

@robertwu1
Copy link
Copy Markdown
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