Fix issue 2025872: Deadlock in SoundPool.stop

There were 2 problems in SoundPool:

1 If not using the shared memory buffer mode, there was a problem when a sound channel was stolen. The new channel could sometimes not be added to the restart
list if the AudioTrack callback thread was stopped before the underrun callback was called.

The SoundChannel::play() method is modified so that SoundPool::done() is called immediately after stopping the channel. There is a possibility that done() is called a second time by the callback; in this case it will be added 2 times to the restart list but the second start request will be ignored as the first one will have reset the next chennel ID when processed.

2 There was a deadlock on SoundPool::mLock if SoundPool::stop() was called while a channel restart was pending:
 SoundPool::stop() lock mLock -> SoundChannel::stop() -> SoundPool::done() -> SoundPool::addToRestartList() -> try to lock mLock == deadlock

A second mutex mRestartLock is added to protect the restart list mRestart. mLock is still used to protect mChannels list but mRestart is now used to
protect access to mRestart by restart thread and client thread.

0 files changed, 0 insertions, 0 deletions