Possible deadlock in AudioInputStreamOpenSLES::close()

[philburk]

A third-party developer wrote in an email:

...we are suspecting there might be a deadlock in the OpenSL implementation of the close() method called on the Input stream, namely: AudioInputStreamOpenSLES::close(). While we aren’t currently able to repro the problem on any of our devices, our logs indicate that a large number of devices are timing out (take more than 10 secs) waiting on the call to return. This happens when both input and output streams are opened and we stop the input stream.

Our integration uses the latest public Oboe release and creates a managed stream and we simply call stream_->stop() followed by stream_-flush(). We know the thing deadlocks there because we fire an event when close returns and we don’t see this event in the cases we mention.

Here’s the top 10 devices that this occurs on:

[various Vivo and Redmi devices.]

And the top 3 Android versions:

• Android 9
• Android 8.1
• Android 7

I noticed this in AudioInputStreamOpenSLES::close()

  mLock.unlock(); // avoid recursive lock
  requestStop();
  mLock.lock();

[We think] a race can occur here, right before and right after calling requestStop();

[Consider using] std::recursive_mutex

[philburk]

We addressed a race condition in the AAudio side that seems related:

    #1017

We should consider adding the same change to the OpenSL ES side.