Since moving to the OpenAL audio API I've noticed a lag/hiccup that occurs when multiple sounds are being played in rapid succession, that didn't occur when using the Corona media API.

When this occurs all audio sort of stutters for a few moments until the number of sounds being played diminishes. The number of sounds requires to do this seems to be about 16-22.

This is a lot of sounds to be playing at approximately the same time, but I never encountered this with the Corona media API. The reason I shifted to the OpenAL audio API is because of the ability to load sounds from the DocumentsDirectory.

Is there any way to avoid this with OpenAL?

Thanks

I'll assume you are using audio.loadSound and not using audio.loadStream for all of your 16+ sounds. Also read the Audio Notes page about performance tips (e.g. setting the frequencies lower and all the same, etc.)

I'm going to guess this is on Android? If so, short answer is audio sucks on Android and that's the only reason we haven't officially deprecated and removed the old media.eventSound API. The media.eventSound wraps a really limited API on Android, but was given a special shortcut to minimize problems you described (but still susceptible). But it is too limited and stupid to be useful in the general case so OpenAL is built on Android's other audio API which is more powerful but more vulnerable to the problems. (I just saw Angry Birds on an Android tablet for the first time...I saw a 2-3 second lag in sounds even there which tells me they are using the more general API.)

Moving to Android 2.3+ opens up the door to a better audio API (OpenSL), but unfortunately Google failed to get device manufactures to upgrade devices so the majority of devices are still 2.2. Also, unfortunately, Android's performance problems go down as far as the kernel so OpenSL won't necessarily fix those. Google must fix the kernel.

If your problems are on iOS, I'm surprised that the media.eventSound API is performing better than OpenAL and hasn't introduced other subtle bugs like things not actually playing. File a performance bug with Apple in that case.

If this is a real problem for you, I recommend you limit the number of playing sounds to 16 (or less) at any given time. You can start simple by using audio.reserveChannels(16) which eliminates half of the 32 auto-assigned channels so when you exceed the number, sounds fail to play. Or you can build your own resource management system to customize how you want to reclaim channels when you run out.

@ewing

Yes the issue is with audio.loadSound, and it's only on Android Gingerbread, tested on a Nexus One & Nexus S.

And actually with Android Honeycomb tablets the audio performance is much improved using audio.loadSound. So there might be hope ; )

Am I right in thinking that there isn't a way to use media.eventSound with files in the DocumentsDirectory? If there isn't I'll try limiting available channels.

Thanks for the detailed response = )

I'm not sure. The docs suggest you should be able to specify a base directory.
http://developer.anscamobile.com/reference/index/mediaplayeventsound

But if it doesn't work, it wouldn't really surprise me.

@ewing

Ah, thanks!! There appears to be conflicting information in the documentation here: http://developer.anscamobile.com/content/multimedia-features

media.newEventSound( soundFile )

Loads the event sound (1-3 seconds) from soundFile and returns an event sound id that can be passed to media.playEventSound. Currently, the sound file must be in the application resources directory (see System-defined directories).

I understood that to mean the system.ResourcesDirectory