So, basically before the build 540 (<539), when my app was suspended (lock the screen or double click the home button to open the background app list) the audio stopped, and started playing again when the app was resumed.
On build 540 however it looks like when the app is resumed the audio doesn’t work anymore. I’ve tried audio.dispose and loading again but it gives me a “WARNING: Failed to create audio sound” error.
(using audio.loadSound and audio.play)
PS: Basically, I was testing the audioSession and ios backgrounding in 540 beta. It was working nicely, however the sound sometimes stopped playing. So I removed all the audioSession/background functions and tested the basic app with 540 and 539.
[import]uid: 9158 topic_id: 11283 reply_id: 311283[/import]
Just to make sure, I’ve even set the UIBackgroundModes key in plist (with 540 of course), result is still the same. [import]uid: 10478 topic_id: 11283 reply_id: 41091[/import]
And just to update, just tapping the home button to go back to the home screen loses the audio too. the only thing that does work is double-tap home button, go to another app, and then double tap to go back to the original app. that works fine. home and then double tap back to the app and no sound.
I’m always on the bleeding edge builds, so I’m glad to know I wasn’t coding wrong when I was experiencing this issue.
Knock on wood, it’s the first bug I’ve ever experienced in a newer build. Your Kung Fu is strong, Ansca. [import]uid: 6084 topic_id: 11283 reply_id: 41169[/import]
Please be aware, the backgrounding feature is incomplete and it is not officially supported yet. We still reserve the right to completely break any apps that use this feature and we do not want to see any bug reports with test examples that use any unsupported features.
There are hard limitations in using it, most notably that while the underlying audio engine will continue to play, the Corona core still suspends. This means event callbacks (like onComplete) will not fire until the app is resumed. The main reason we do this is because any attempt to make (OpenGL) drawing calls on iOS while backgrounded will result in iOS killing your process and likely App Store rejection. And attempting to do more processing that what is deemed appropriate by Apple will also be grounds for App Store rejection. So we feel we need to design/implement more constrained rules/APIs to manage and cooperate within Apple’s expectations of backgrounding.
@ewing: No worries from me… I just want the ability for someone to double-tap out of my app and be able to double-tap into it without waiting the 4 to 7 seconds for it to “reboot” itself.
For our practical use, I’ve turned it on with our “Writing Prompts” app and “Dramatic Music App”.
Dramatic Music App does have loops, and they do successfully keep playing when you background the app. That’s great and I hope that continues to work, but the non-load time when switching back to the app is most exciting. For example, you can then use the app to play a funny dramatic music piece BEFORE the moment in the conversation has passed… prior to this, it’s more like “wait a minute while i load the app … pause … ok, now here’s the funny sound.”
Likewise, with Writing Prompts, the benefit has nothing to do with anything running in the background … and is the simple act of being able to keep the Writing Prompts open, double-tap over to the “Notes” or “Email” application and then double-tap back over to the Prompts app while it’s still open and in the same state, without any wait time for re-loading.
The only “code” I’m using is the change to info.plist to not exit the app on suspend. I think it’s awesome. (Have I said that?)
So, **pretty please** … if you break it, do leave the basic functionality of being able to use this very basic backgrounding. And do keep in mind that a lot of are writing more simple apps that don’t use OpenGL and the like… so real simple support for this is all we need and it’s still a huge leap forward.
Quick notes:
If you only care about fast suspend and resume, defining:
UIApplicationExitsOnSuspend = false
without setting UIBackgroundModes to anything should be sufficient.
UIBackgroundModes is only to request processing while background and is subject to additional Apple scrutiny in the review process.
Also, if you only care about music playing during screen lock but not backgrounding, instead of setting UIBackgroundModes, you might just try setting the mix mode to audio.MediaPlaybackMixMode.
Yesterday I noticed the same “Error setting audio session active to 0! ‘!act’” on 544 and 545, happening in the suspending/resuming phase.
I’ll check with the latest build.
[import]uid: 9158 topic_id: 11283 reply_id: 41804[/import]
Just tested with build 547, unfortunately it didn’t go away yet… Same msg on both iPad & iPhone4.
Suspend appears to be workingbut when resuming after app is full screen there appears to be a momentary lag (on both animation & sounds). I don’t remember noticing that before… [import]uid: 10478 topic_id: 11283 reply_id: 41883[/import]
So I just retested on 547 with the following code.
local function onSuspend( event )
print("In onSuspend", event.type)
if event.type == "applicationSuspend" then
elseif event.type == "applicationResume" then
end
end
Runtime:addEventListener( "system", onSuspend )
music = audio.loadStream("background.mp3")
audio.play(music, {channel = 1, loops=-1})\
I see the error message only when I run the app normally, but not when I run through the Xcode debugger. Very strange. It doesn’t seem to hurt anything for me though which is what I’m more concerned about. (Apple goofed here and they don’t have an API to query the current active state so I have to take a leap of faith and set the value even if the value has already been set which seems to return an error in this case.)
I don’t experience the resuming hiccup, but my test case may too simple.
Just tested your code on 549, it’s still there but nothing major I guess…
Also forget about the hiccup, just tested Angry Birds and same hiccup is there both for sound & graphics. Does not happen at the first time or all the time, so it looks like an apple thing… [import]uid: 10478 topic_id: 11283 reply_id: 41997[/import]
