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
This affects:
- IAudioFlinger::openOutput
- AudioTrack::AudioTrack
- AudioTrack::set
- apps that call these
Change-Id: I26fb281bac6cb87593d17697bc9cb37a835af205
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
We can help you with that.
Note also that getParcelFileDescriptorFD did no such thing. All its callers
were passing in a regular java.io.FileDescriptor and expecting the int. No
ParcelFileDescriptors involved.
Change-Id: Idc233626f20c092e719f152562601f406cc1b64a
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
SoundPool itself also creates a thread, which was called "SoundPoolThread", unrelated to the SoundPoolThread class. The SoundPoolThread class then created an unnamed thread, which showed up as "android:unnamed_thread". That's confusing, so this change renames the SoundPool thread to "SoundPool" and then names the SoundPoolThread thread as "SoundPoolThread". Say that ten times fast :)
Change-Id: I67b7e644a30c94b6eda44bf970764a52a1c2958b
AudioTrack was modified earlier to calculate minimum buffer size
based on the hardware reported latency. Previously, it was a
hard-coded value. As a result of this change, the minimum buffer
size is now variable based on hardware latency. On Passion, this
brought out a subtle rounding error in the buffer size calculation
in SoundPool. This can cause AudioTrack creation to fail based on
the requested sample rate. This fix calculates the total buffer
size first, and then does rounding before dividing by the number
of buffers.
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.
Initial commit for review.
Integrated comments after patch set 1 review.
Fixed lockup in AudioFlinger::ThreadBase::exit()
Fixed lockup when playing tone with AudioPlocyService startTone()
