Thanks for the bug. There are a couple of different things going on here.
First, I think we should ignore iOS 5.0. It’s not going to get any better because of the Apple regression bug.
Second, once we disregard iOS 5.0, then only Lion has the problem. Since Snow Leopard nor the other iOS versions have this problem, I think it is worth filing a performance regression bug with Apple. Would you mind filing a bug with Apple with all the information you have provided us (and maybe a short blurb on how to run in Corona). You can also put my name in your bug report and say Corona/ALmixer and they are free to contact me for more info. (They know who I am.) But you have actually done much better testing on this issue and know it better, so I would like you to be the point on the bug.
Third, you should be aware of performance/implementation details of ALmixer which partly explain the hiccup I’m seeing in the frame rate. (This is not an continuous audio playback stuttering problem I’m seeing.)
audio.loadSound is built for low/latency, high performance. This is best for short sounds that need to go off immediately. It was built so you can fire a lot of these simultaneously (e.g. 32). It partly achieves this by pre-decoding the entire sample into RAM.
audio.loadStream is built to keep a lower memory profile by reading small chunks at a time. Because of this, it has higher latency. In your particular example, you are only using a second of your bgmusic and I think you could get away with having a much shorter crowd chatter loop. Moving these to loadSound would avoid the performance issue.
But assuming you can’t do this for some reason, there are specific implementation details you should be aware of. First, there are also start up costs when starting to play a loadStream. If there are no buffers ready to go, some buffers must be read before play can start. This currently happens on the main thread so there can be a pause. However, we have tried to tune this so it seems quick in the common case and you don’t notice a pause. Hence, I am surprised that you don’t see the problem on iOS, but do have it in Lion (but not Snow Leopard. This is why it is good to file an Apple bug.
When you call audio.loadStream for the first time, the implementation currently makes an optimistic assumption that you will be playing from the beginning, so a couple of buffers are queued here. This is why you might not see a hiccup after the first play.
But when you stop or seek or rewind, any pre-read buffers must be thrown away and new buffers must be read. So in your example, when you rewind and stop, you are actually creating more work that needs to be done which can also be a factor in creating a hiccup.
For your example, you call:
audio.rewind(CHATTER_CHANNEL);
audio.stop(CHATTER_CHANNEL);
As an implementation detail for audio.loadStream (which could change, but probably won’t), this might be slightly better because it avoids any possible new buffering that needs to be done in rewind:
audio.stop(CHATTER_CHANNEL);
audio.rewind(gameAudio[“crowdChatter”]);
However, in your case, a much better solution is this:
audio.pause(CHATTER_CHANNEL);
audio.rewind(CHATTER_CHANNEL);
And then call audio.resume(CHATTER_CHANNEL) when you want to play it again.
Again, as an implementation detail, when audio is paused, the background thread continues to pre-read more buffers. So when you finally get around to calling resume, there is no need to read more buffers so there is less latency.
When I did this, the latency went away for me in your example on Lion.
So please file an Apple bug and post it here and/or in your bug report with us.
[import]uid: 7563 topic_id: 18439 reply_id: 71698[/import]
