As far as I know you can’t play sounds loaded by audio.loadSound() with the media.* API.
For this reason alone, I’ve written my own audio library that automatically uses the media.* API on Android < 4.2 and otherwise uses the audio.* API.
Unfortunately I can’t share the code.
But the gist of it is to write a module with your own loadSound() and playSound() functions.
The loadSound(id, fileName, {isShort=true | false}) function checks for Android and if it’s defined as a short sound will load the file using the media.* API and store the returned handle in a table appAudio[id].handle with a type of appAudio[id].type = “media”.
For long sounds (isShort = false) or omitted / iOS, I use the audio.* API to load the sound into the table appAudio[id].handle with the type of appAudio[id].type = “audio”.
The playSound(id) function will check appAudio[id].type and use the appropriate API to play the handle stored in appAudio[id].handle.
You’ll also need some housekeeping functions to only keep your active handles in memory while you change scenes etc.
The major drawback of the media.* API is that only one sound can be played at a time. If you play a second sound before the media.* API had finished playing the current sound, it will stop playing the first sound before playing the second one. This can cause “ugly” abrupt sound effects if you have a fast paced action scene where you want to play short sounds in quick succession.
So sometimes you’ll have to make a decision to either have nice sound effects with a slight delay, or to have sounds played on-time, but with less-than-perfect results.
It’s a dilemma I struggle with every time on Android…
So I guess it’s still there. Though I encountered problems with the media.* API on a S4 GT-I9505 Android 4.4.2 where sounds would not play . Some of the audio files would play fine though. All mp3 at 128kbit, so i have no clue. I converted them to .wav files and they all would play. Anything I should watch out for? (Though .wav files are fine for me)
@Rob For the audio.* API: The latency on a Samsung Galaxy S4 GT-I9505 Android 4.4.2 is huge with mp3. With .wav 44,1kHz it’s like half, but still not near acceptable for a game. So even a check for Android version wouldn’t suffice. I think it should be included in the docs somewhere, that you should not use the audio.* API for Android at the moment
Unfortunately with Android you are not dealing with the exact same operating system from device to device. Each device maker may include their own code or have different audio decoding hardware. In other words, not all drivers are made the same. I would suggest making your audio files as small as possible, perhaps 11khz mono sounds. Pre-load them where it make sense.
Rob
Are you talking about media.* or audio.* API? So 11kHz mono sounds work on Android using the audio.* API (I presume) works okay? About preloading do you mean media.newEventSound and audio.loadSound? For that I’m doing this already.
Both media.* and audio.* have to deal with the devices CODEC for the media type you are trying to use. The audio.* has an extra layer between the app and the OS called OpenAL which is a standard for doing Audio. Prior to Android 4.2, Google had a delay bug in their OpenAL layer, which is why for time critical sounds we recommend media.newEventSound since it bypasses OpenAL and therefore the bug in it for Android 4.1 and earlier.
This bug isn’t the only source of audio lags that can happen. The size of the sound, the amount of decoding the CPU has to do on it, the how well the sound was encoded in the first place, other CPU tasks going on all impact when the CPU can play the sound.
Both media.* and audio.* should be able to deal with the 11khz sounds. The idea is to get the leanest memory foot print per sound as you can get to reduce the amount of CPU and memory transfer time. You should also consider looking at your app to see if these lags are happening around other CPU intense moments. Also try to find a variety of Android apps to test on (see if you can install it on a friend’s device).
Rob
Thanks, I’m gonna try 11kHz sounds then with media.* and audio.* I’m starting closed beta tests soon, so I’ll get a variety of results by then.
So I guess it’s still there. Though I encountered problems with the media.* API on a S4 GT-I9505 Android 4.4.2 where sounds would not play . Some of the audio files would play fine though. All mp3 at 128kbit, so i have no clue. I converted them to .wav files and they all would play. Anything I should watch out for? (Though .wav files are fine for me)
@Rob For the audio.* API: The latency on a Samsung Galaxy S4 GT-I9505 Android 4.4.2 is huge with mp3. With .wav 44,1kHz it’s like half, but still not near acceptable for a game. So even a check for Android version wouldn’t suffice. I think it should be included in the docs somewhere, that you should not use the audio.* API for Android at the moment
Unfortunately with Android you are not dealing with the exact same operating system from device to device. Each device maker may include their own code or have different audio decoding hardware. In other words, not all drivers are made the same. I would suggest making your audio files as small as possible, perhaps 11khz mono sounds. Pre-load them where it make sense.
Rob
Are you talking about media.* or audio.* API? So 11kHz mono sounds work on Android using the audio.* API (I presume) works okay? About preloading do you mean media.newEventSound and audio.loadSound? For that I’m doing this already.
Both media.* and audio.* have to deal with the devices CODEC for the media type you are trying to use. The audio.* has an extra layer between the app and the OS called OpenAL which is a standard for doing Audio. Prior to Android 4.2, Google had a delay bug in their OpenAL layer, which is why for time critical sounds we recommend media.newEventSound since it bypasses OpenAL and therefore the bug in it for Android 4.1 and earlier.
This bug isn’t the only source of audio lags that can happen. The size of the sound, the amount of decoding the CPU has to do on it, the how well the sound was encoded in the first place, other CPU tasks going on all impact when the CPU can play the sound.
Both media.* and audio.* should be able to deal with the 11khz sounds. The idea is to get the leanest memory foot print per sound as you can get to reduce the amount of CPU and memory transfer time. You should also consider looking at your app to see if these lags are happening around other CPU intense moments. Also try to find a variety of Android apps to test on (see if you can install it on a friend’s device).
Rob
Thanks, I’m gonna try 11kHz sounds then with media.* and audio.* I’m starting closed beta tests soon, so I’ll get a variety of results by then.