you need to share those 32 with rest of the system),
and AudioTrack is used internally beneath SoundPool, ToneGenerator,
MediaPlayer, native audio based on OpenSL ES, etc.
But the actual AudioTrack limit is < 32; it depends more on
soft factors such as memory, CPU load, etc.
Also note that the limiter in the Android audio mixer does not currently
have dynamic range compression, so it is possible to clip
if you have a large number of active sounds and they're all loud.
For video players the limit is much much lower due to the intense
load that video puts on the device.
I'll use this as an opportunity to remind media developers: please
remember to call release() for media objects when your app is paused.
This frees up the underlying resources that other apps will need.
Don't rely on the media objects being cleaned up in finalize
by the garbage collector, as that has unpredictable timing.
On Saturday, April 28, 2012 3:40:25 AM UTC-7, Tamás Kovács wrote:
In my game app, I use SoundPool for quick short sounds, but I also
employ a few instances of MediaPlayer for certain reasons (more rich
control, getCurrentPosition/seekTo, etc.).
More precisely, 1 MediaPlayer is playing a longer sound (~3 MB), and
3-4 other MediaPlayers are used for small sounds (40-80 KB). The
longer sound is played all the time, the small sounds are occassional
(but I keep all MediaPlayers in prepared state).
I read somewhere that the system doesn't expect me to use more than 2
MediaPlayers at the same time. Is this because of their bigger
footprint and complexity (and thus bigger memory usage), or is there
some other (formal) restriction too?
(If it's only an empirical limit related to memory usage, then I
suppose it's fine to use many -- e.g. five -- MediaPlayers *provided*
the loaded sounds are small.)