Just tested with the latest stable release (591) and it’s working OK.
It still dumps an error msg tough, “: Error setting audio session active to 0! ‘!act’” [import]uid: 10478 topic_id: 11283 reply_id: 54085[/import]
I can confirm audio on suspend/resume also works OK on 2011.606
I guess mixer changes on 608 caused this… [import]uid: 10478 topic_id: 11283 reply_id: 54092[/import]
Thanks for isolating the build. I just committed a fix for this and should appear in the next daily build. [import]uid: 7563 topic_id: 11283 reply_id: 54127[/import]
Thank you for looking into this…
But I’ve just tested it with newest build 2011.611 and the problem still exists…
But it behaves differently listed as follows:
* Previous error msg is gone.
* For few occasions (cannot reproduce) audio worked fine on resume but just for the first try. If I suspend/resume again it wouldn’t play.
* Now I receive the following error on console : “: Error with unqueue: Invalid Value, buffer id is 0”. When that happens, 7 instances of same error msg posted.
* I think (but not sure) above error posted on the second run. Which means: 1. Run the app, 2. suspend/resume, 3. quit the app, 4. re-run.
* When the game resumes, there are 2-3 lags on animation for the first few seconds. Like app is trying to access/init something…
Btw, I’m using IP4 with 4.3.5 [import]uid: 10478 topic_id: 11283 reply_id: 54146[/import]
This one looks ugly. For the audio not resuming, right now I’m under the belief that we’ve hit a race condition in Apple’s OpenAL implementation where resuming the audio gets clobbered by something else later and the audio ends up pausing again. (As a work around, you might be able to call audio.resume() a few seconds after app resume.) Interestingly, I seem to hit this on iPad 2 but not iPad 1. (Haven’t tried iPhone.)
I’m working on a work-around because I think I’ve isolated a piece that triggers the race condition. Unfortunately, the work-around will not be able to help true iOS audio interruptions like phone calls.
I’m not sure what is causing the errors or the lags. I saw the errors once, but after I changed a bunch of code for the work-around, I don’t see it anymore. The lags I haven’t seen besides an initial resume frame rate jump but this is present in Apple’s own examples.
I might try to push the work-around tomorrow. It’s scary code and needs a little more testing before I push it in. Once I do push it in, you should all thoroughly test it because there are lots of serious changes.
[import]uid: 7563 topic_id: 11283 reply_id: 54654[/import]
Thank you,
I have an iPad 1, I will test on that too.
resuming the audio gets clobbered by something else later and the audio ends up pausing again
I agree that might be the case as when resumed, I hear audio for a very brief period (like 1/4 a sec). I though that might be the audio left in buffer but your explanation fits better.
I have also tested 608, so I can confirm 606 is the last good build.
Also my phone call interruption bug report seems related to the issue,
http://bugs.anscamobile.com/default.asp?6575_dl9n6l04 [import]uid: 10478 topic_id: 11283 reply_id: 54683[/import]
An update, if that helps…
I have re-tested 611 on both iPhone4 & iPad1
* Forget about the extra lags. I have rebooted both devices and killed all tasks and it was OK. There were no other lags than the regular apple resume lag.
* For normal suspend/resume (Home button) I could not get any error messages this time. Again as I noted above, on resume, audio plays just a bit before it gets killed.
* I have also re-tested for my above bug report. When resuming from a canceled phone call, that brief audio playback is not happening. It just resumes silent and below error msg posted on console…
[text]
unknown mediaserverd[19] : 11:25:49.100 WARNING translating CMSession error: -12985
unknown 3[3435] : Error setting audio session active to 1! '!cat’
unknown 3[3435] : 11:25:49.110 <0x3f32d48c> AUIOClient_StartIO failed (-12985)
[/text]
3 is my app name… [import]uid: 10478 topic_id: 11283 reply_id: 54684[/import]
Please try and reproduce the bug in the Corona Simulator (Mac) using the Hardware/Suspend command.
Build 611 gives problems with that as well apparently.
Edit:
It looks like system resumes close to each other (1 second or less) cause Simulator not to resume audio.
If you start testing afresh and resume after suspend for a longer while, music resumes normally.
Edit2:
On my machine and with an mp3 file, the “resume grace period” seems to be around 2 full seconds. [import]uid: 5750 topic_id: 11283 reply_id: 54728[/import]
Interesting find about the Mac. Testing my new workaround seems to avoid the problem on the Mac too. I think this suggests the Mac has the same OpenAL bug as iOS (not too surprising since it would make sense for Apple to share the same code base).
I filed Apple bug rdar://10081775 which is mirrored here: http://openradar.appspot.com/radar?id=1334407
I encourage you to file duplicate bugs with Apple and refer to my bug id letting them know you are affected by it to help boost the priority. Also, if you have more information that may help them, please include that in your bug reports.
[import]uid: 7563 topic_id: 11283 reply_id: 54748[/import]
Great work!
Just installed 2011.613 and I’m happy to say your workaround appears to fix that issue… 
Tested on both iPhone4 & iPad1.
Few notes just to let you know:
That msg is back “: Error setting audio session active to 0! ‘!act’” for home button suspend/resume. Msg printed after suspending.
My bug report still stands. If I accept/reject the call audio on resume is ok. If I do nothing and caller cancels there is no audio (not just the current screen, for life of the app. Only way to restore is killing the task and re-staring the app).
I’ve tested few other apps and they behave correctly so I assume that is Corona related.
Below is the console output after canceling the call.
[text]
Sep 8 14:16:45 unknown 3[3553] : Error setting audio session active to 1! '!cat’
Sep 8 14:16:45 unknown 3[3553] : 14:16:45.493 <0x3f32d48c> AUIOClient_StartIO failed (-12985)
[/text] [import]uid: 10478 topic_id: 11283 reply_id: 54842[/import]
We just pushed in another workaround for your interruption bug. I think we found 2 more race conditions in Apple’s frameworks related to this. That makes 3 this week
[import]uid: 7563 topic_id: 11283 reply_id: 54964[/import]
Thank you!
Just tested 2011.615 on the iPhone4 for the bug…
It’s working, but not 100%.
That might be small fix from here so just wanted to report in.
Regular home button suspend/resume working OK.
Phone call suspend/resume has a different behavior now:
* It doesn’t differentiate if the caller cancels OR I hit accept/reject.
* When resumed, app has audio ability. Restoring audio does not require killing the task anymore.
* Audio started after the resume (collisions, buttons, etc.) are working ok.
* Any audio (streaming or not) playing while suspending is NOT restarted on resume.
* If I issue resume command (audio.resume) that audio also starts playing.
* There are no errors posted to the console.
I hope this helps… [import]uid: 10478 topic_id: 11283 reply_id: 55051[/import]
That sounds like the first race condition bug described a few days ago. As I said, our workaround for that was to avoid changing the OpenAL context on suspend/resume, but interruptions may still be susceptible because changing the OpenAL context is required in the latter case. When an (begin-)interruption event suspends the app, for audio purposes, the app resume is considered to be an end-interruption event.
We did not encounter this race condition in our testing yesterday, but since we’ve seen this on both iPad 2 and Mac, I believe it exists; it just doesn’t always happen. You somehow manage to trigger it every time.
Unfortunately, the only workaround we have left for this is to inject yet another sleep in the code and hope it’s long enough. Since this is hard for us to reproduce, we’re going to have to guess at the magic number. But obviously this is going to impact the interruption-resume behavior and may make jumps/lags which you complained about before even worse.
Again, everybody should file a duplicate bug report as described above to Apple about this.
[import]uid: 7563 topic_id: 11283 reply_id: 55116[/import]
One more thing, the other errors on the console you see are results of other bugs, mostly fall out from the 3 race condition bugs we discovered in Apple’s implementation. You may still see these in the future. The most serious is the AUIOClient_StartIO which comes from Apple and that’s what the first sleep tries to avoid.
The next is 'Error setting audio session active ’ which can happen in both serious cases and ignorable cases. The ignorable case is when we set the state to the state that is already set. Apple’s API is missing a way to ask what the current state is (aka defective/deficient) so we must set it blindly. The state can change out from under us by Apple so it is hard to know what the state is.
The ‘buffer’ messages usually trigger right when a phone call interruption comes in. This is the third Apple race condition bug we found. My theory is that something is happening to/corrupting the audio system behind the scenes before we get notified by the interruption event callback. So there is nothing we can do to fix this. So far, audio seems to continue working despite the problems so you might be able to ignore these messages.
[import]uid: 7563 topic_id: 11283 reply_id: 55117[/import]
Thank you for your detailed reply. You are right about the Apple bugs, actually device console is crowded with these…
Just to make sure I have complied Martian Control sample to test again.
http://developer.anscamobile.com/code/martian-control
Just added “UIApplicationExitsOnSuspend = false” to the sample code.
Test device is an iPhone4 with 4.3.5, complied on 10.6.8 with xcode 4.0.2 (4A2002a) using CSDK 2011.615
Phone call interruption suspend/resume behaved the same as my app and yes you are right, some how I’ve managed to trigger it every time.
On the menu screen, music keeps playing after regular suspend/resume. But it’s not coming back after a phone call interruption suspend/resume.
Your recent workaround was an important one, as the app still has the audio ability after the canceled call.
I think (hope) I can use event.type to detect and pause/resume the audio. [import]uid: 10478 topic_id: 11283 reply_id: 55121[/import]
I just added another 1 second sleep in the end-interruption and kicked off a daily build early. I would appreciate it if you would test the new build and let me know how it works since you can reproduce the problem so easily.
[import]uid: 7563 topic_id: 11283 reply_id: 55123[/import]
Of course!
I’m downloading it right now and report back shortly… [import]uid: 10478 topic_id: 11283 reply_id: 55137[/import]
2011.616 tested on both devices and…
Works perfectly!
Tested each scenario (home button, cancel call, reject call, etc.) and all sounds resumed back correctly every time.
Initial lag is a bit longer now, as you have explained above. But that is ONLY true when resuming form a phone call interruption.
Regular resume is unaffected working as before, without any extra lags… Also there are no subsequent lags in both cases.
Hats off to you for solving Apple’s bug for us… 
[import]uid: 10478 topic_id: 11283 reply_id: 55138[/import]