Not sure if I am approaching this correctly. I have a room-based game where each room can have up to three mp3s playing at various volumes. I also need any previously playing mp3s to fade out. What I am doing then, is instantiating three ofSoundPlayers and calling loadSound with streaming enabled. I also call the destructor on the previous ofSoundPlayers.
This seems to be causing all manner of audio glitches. There is a large amount of stuttering before the new sounds play, sometimes the sounds don’t play at all and sometimes the sounds from the destructed ofSoundPlayers keep playing.
I tried disabling streaming (so that the underlying implementation is SoundPool instead of MediaPlayer) but in that case no sound played at all and I got errors about exceeding buffer size. That is sort of expected, based on what I know about SoundPool.
Anyways, is it realistic to expect good performance from this situation? I just want to load and play three large mp3s at the same time it seems within reason.
P.S. Also, as a point of personal curiosity does MP3 decoding on Android use hardware acceleration? I thought that might be the culprit but then I saw this off-hand remark here which makes me think it’s actually not a big deal:
" The audio data is decoded by FFmpeg directly, which does not cost much CPU workload.”
audio in android is pretty terrible, even if you get it to work in a device you’ll have trouble for sure in others. i’m not sure what’s the situation with new devices but it’s really complicated to get anything even basic to work properly in a reasonable amount of devices.
the ideal would be to have an opensl implementation but even that seems to change depending on the device and being even more low level and done in native code it’s easier to make the app crash.
also re mp3 decoding, i guess it depends on the device, in most devices since some years ago, with more than one core it’s probably negligible even if it hapens in the cpu
Yikes, that is pretty bad news! I had a more basic implementation working earlier with only one MediaPlayer and no construction/destruction per room. I might give that another shot and see. It’s just so hard to debug and understand what’s going on here. I just spent a few hours reading about stagefright/awesomeplayer/mediacodec/omxplayer and I don’t feel like I’m any closer to understanding what is breaking in my code and why.
As a side note, it looks like FMOD for Android is free of charge for projects under 100k budget. I might give that a shot.
Is the situation any better with AudioTrack (I assume that’s the ofSoundStream implementation)? Or do most the problems revolve around buffered encoded audio-video?
AudioTrack is also pretty bad, depends a lot on the device but most devices have a really long latency, at least in devices from a couple of years ago, not sure what’s the situation right now.
might be worth looking into fmod
Just a small follow-up, I’ve tried what feels like a hundred different ways to get MediaPlayer to work to no avail.
Using uncompressed audio (.wav.) didn’t seem to help at all. The number of active MediaPlayers (2-8) also seems to have no effect. Whether or not I release() and then new() or just call reset() doesn’t make a difference – that is to say, creating a new MediaPlayer for each track or just using the same fixed set of MediaPlayers over and over produces the same effect.
I tried throttling my usage of MediaPlayer.setVolume() so that I only call it every ten frames or so and that sort of helped but didn’t fix the problem of auto being choppy and sometimes stopping for no reason.
I also tried spinning off a thread for MediaPlayer.setVolume() since for whatever reason that call was pegging the CPU (I am calling it often to fade in and out my multitrack audio).
I have heard of using MediaPlayer as a service using an AsyncTask but I don’t think I’m going to try that.
Similarly, this page suggests basically rolling your own mixer but I don’t think I can pull that off in time:
Going to try ExoPlayer then FMOD then who knows. Yeesh!