MediaPlayer - Streams and decodes in real-time for local or remote files. Good for long clips and applications such as background music. More CPU and resource-intensive. Relatively long initialization time. MediaPlayer is a state machine!
"More CPU and resource intensive."
Why would we use MediaPlayer for long audio tracks if it's resource intensive? Wouldn't that just waste a ton of memory over time?
Joe McMillan wrote:... Why would we use MediaPlayer for long audio tracks if it's resource intensive? Wouldn't that just waste a ton of memory over time?
I don't think MediaPlayer memory utilization increases over time, but it sounds like each instance does consume a significant number of media-related resources (which would include memory) so you should probably not keep the instance hanging around longer than needed.
The use cases for SoundPool and MediaPlayer are different.
SoundPool is intended to be used for relatively short clips which can be played without any startup delay. This is accomplished by loading and decoding the sound resources in to memory up-front when the sound pool is created. The length of the audio tracks in limited, and depending on the quality of the audio track, it could be capped at 10 seconds or so. SoundPool allows multiple audio streams to be played at the same time. A classic use case for SoundPool would be sound effects for a game (gun fire, explosions, etc.).
MediaPlayer is intended to be used for playing longer (even unbounded network-streamed) audio tracks. The sound resources are loaded in chunks and the decoding is done on-the-fly. MediaPlayer only supports playing a single audio stream, so if you wanted to play multiple streams concurrently, you would need to have multiple instances of MediaPlayer. An example use case for MediaPlayer would be a music player or podcast app.