I have OpenAL effects and AVAudioPlayer music both working fine. During my game I poll AVAudioPlayer.playing once per frame to see if I should load the next music track, where I release and reallocate AVAudioPlayer to start a new track. But when I am playing a large number of samples through OpenAL (around 30), reading AVAudioPlayer.playing crawls to a halt, taking like 30-200ms, has anyone encountered this? Is there a setting to fix it or should I just hack it and stop reading AVAudioPlayer.playing every frame?

It probably requires synchronizing with the AVAudioPlayer thread. I've noticed if you don't set your audio priority of your app correctly, then the audio threads actually block call from the main thread if they are using to much CPU or something. It's possible that is what's happening here.

Can you not implement AVAudioPlayerDelegate and handle audioPlayerDidFinishPlaying to detect when the song finishes?

I am having some issues with audio causing stuttering on a 3G and I am very interested in your comments there Skorche. Can you give any more info?

Whoops. Not audio priority, audio session category.

One project that I was working on had terrible performance on a non-3GS device when using both OpenAL and an AVAudioPlayer. I couldn't figure out what was wrong as the game wasn't even using that much CPU. It turns out that all we had to do was change the audio session category. The documentation doesn't mention anything about thread prioritization that I could find, but it definitely was doing something of the sort.

The audio session category does enable or disable the use of the hardware sound decoders, but given that I wasn't using that much CPU I'm not convinced that was the only issue.

(Aug 31, 2010 04:19 PM)headkaze Wrote:  Can you not implement AVAudioPlayerDelegate and handle audioPlayerDidFinishPlaying to detect when the song finishes?

I could, but not easily as my audio engine is abstracted from a base class and several of my games use it.

(Aug 31, 2010 07:23 PM)Skorche Wrote:  Whoops. Not audio priority, audio session category.

One project that I was working on had terrible performance on a non-3GS device when using both OpenAL and an AVAudioPlayer. I couldn't figure out what was wrong as the game wasn't even using that much CPU. It turns out that all we had to do was change the audio session category. The documentation doesn't mention anything about thread prioritization that I could find, but it definitely was doing something of the sort.

The audio session category does enable or disable the use of the hardware sound decoders, but given that I wasn't using that much CPU I'm not convinced that was the only issue.

Thanks for the info, what category did you use to 'fix' the issue?

Without looking up the code for it in SVN, I want to say its SoloAmbient or LiveAudio. I think it was UI effects before that, it seemed to make sense at the time. This was a while back though...

I believe it's kAudioSessionCategory_SoloAmbientSound