Reuse channel for same sample if the channel completed
current playback and is not reallocated to another sample,
i.e. not stolen by other sample.
authored-by: Ashish Jain <ashishj@codeaurora.org>
Change-Id: Ibe7ee318c7dc11f3c4fd3a2f57d861318b10973b
Signed-off-by: Glenn Kasten <gkasten@google.com>
Reorganize SoundPool and JetPlayer code to be ready for the
creation of libmedia_native.
Split SoundPool between libsoundpool (JNI) and libmedia(sound pool implementation).
Remove dependencies on nativehelper/jni.h from JetPlayer.
Change-Id: I130c6014173b714329929dd82c5dfb70b757a610
Unconditional delete for raw pointers.
Use "if (sp != 0)" not "if (sp.get() != 0)" or "if (sp != NULL)".
Use "if (raw != NULL)" not "if (raw)".
Change-Id: I531a8da7c37149261ed2f34b862ec4896a4b785b
At native level it was a mixture of audio_stream_type_t, int, uint32_t,
and uint8_t. Java is still int. Also fixed a couple of hard-coded -1
instead of AUDIO_STREAM_DEFAULT, and in startToneCommand a hard-coded 0
instead of AUDIO_STREAM_VOICE_CALL.
Change-Id: Ia33bfd70edca8c2daec9052984b369cd8eee2a83
Was int, uint32_t, uint16_t, and uint8_t with 2-bit bitfield.
Also replace 0 by AUDIO_FORMAT_DEFAULT and replace 1 by
AUDIO_FORMAT_PCM_16_BIT.
Change-Id: Ia8804f53f1725669e368857d5bb2044917e17975
The problem can occur if a sample is started at the same time as the last AudioTrack callback
for a playing sample is called. At this time, allocateChannel() can be called concurrently with moveToFront()
which can cause an entry in mChannels being used by moveToFront() to be erased temporarily by allocateChannel().
The fix consists in making sure that the SoundPool mutex is held whenever play(), stop() or done() are called.
In addition, other potential weaknesses have been removed by making sure that the channel mutex is held while
starting, stopping and processing the AudioTrack call back.
To that purpose, a mechanism similar to the channel restart method is implemented to avoid stopping channels
from the AudioTrack call back but do it from the restart thread instead.
The sound effects SounPool management in AudioService has also been improved to make sure that the samples have
been loaded when a playback request is received and also to immediately release the SoundPool when the effects are
unloaded without waiting for the GC to occur.
The SoundPool.java class was modified to allow the use of a looper attached to the thread in which the sample
loaded listener is running and not to the thread in which the SoundPool is created.
The maximum number of samples that can be loaded in a SoundPool lifetime as been increased from 255 to 65535.
Change-Id: I368a3bdfda4239f807f857c3e97b70f6b31b0af3
Use a Mutex wherever atomic operations were used in AudioTrack,
AudioRecord, AudioFlinger and AudioEffect classes.
Change-Id: I6f55b2cabdcd93d64ef19446735b8f33720f8dbc
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.
