Open jaredsinclair opened 8 years ago
Given those options, I think option 3 (ie. 1 and 2) is the right choice. We'll have to test aggressively whether the background audio change affects any of the app's current behavior around video playback.
We should also add a note to this repository's documentation, so future users of the library will be aware of this limitation (remember, we plan to OSS this repo).
Update To make matters worse, the background audio solution isn't deterministic. It only works in the newsreader application. It does not prevent the crash in the NYTVideo sample application. My guess is that there are race conditions in the newsreader (perhaps administrative tasks that are spawned when the app is resigning active) that alter the time window during which the bug occurs. This is pure conjecture. The point is that the background audio solution might not work for the newsreader app when compiler optimizations are enabled, or on all devices, or in all circumstances.
from the error docs:
or if the app is in the background and using a category which does not allow background audio.
is it possible that Newsreader does some mucking-about with our audio category that the example app doesn't? This might be worth checking into, @jaredsinclair.
Update September 15, 2016 - I've retested this using the GM release of iOS 10 and Xcode 8, and the issue appears to have been resolved on Apple's end.
Update September 19, 2016 – I was mistaken. This issue has not yet been resolved. I was testing incorrectly. The bug can only be reproduced by locking the device, not by sending the app to the background. The crash still occurs on iOS 10 GM.
Here's a link to a sample project that we can send to Apple along with a radar: https://www.dropbox.com/s/kxop5jdlyk9sch5/Core%20Audio%20Crash.zip?dl=0
thanks, @jaredsinclair!
STR
On a device running iOS 10 (must be an actual device, not the simulator), the following STR consistently lead to a crash:
Variations
This occurs whether or not the video is still playing or has been paused prior to the moment the lock button is pressed. It occurs whether or not the AVPlayer, its associated video node, or the entire SKScene have been paused.
Workaround
The only thing I have found that prevents the crash is to add background audio to the app's list of allowed background modes.
Crash Details
The crash is caused by an uncaught exception thrown by CoreAudio:
That error code maps to AVAudioSessionErrorCodeCannotStartPlaying:
This crash does not affect standard videos, so my assumption is that there is something about SceneKit's usage of AVPlayer/CoreAudio which leads to the crash.
Resolution
I've exhausted everything I can think to try. I think we have four options: