Open Radar

 
28-Aug-2012 06:51 PM Eric Wing:
Summary:
I found a race condition in the Apple OpenAL implementation when trying to pause/resume very quickly.
This affects both Mac and iOS.

If you pause and then very soon after call resume, audio will not actually resume.


Steps to Reproduce:
Attached is an example for both iOS and Mac that can reproduce the problem. Build and run both. (Both real iOS devices and the iOS simulator have the problem as well as Mac proper.)


Expected Results:
When you run, you should hear a single laser shot. A callback message should appear in the log after the sound finishes playing. (This is achieved by polling the OpenAL state to figure out when a sound finishes playing.)

Actual Results:
You do not hear the laser shot. You do not get a callback print message in the log.

Regression:
Tried on Mac 10.7 and iOS 5.1. This bug has probably always been around.

Notes:
I you put a sleep before the resume call, then I can get the resume call. This is why I think it is a race condition.


My users are doing this to immediately tell something to seek to a position and then resume playing. The pattern would be:

play()
pause()
seek()
resume()

(A limitation in ALmixer is that you have to start playing to attach a buffer to a source so pausing immediately is the workaround if you want to start playing at an offset.)

This is failing with both iOS and Mac. (It works fine on OpenAL Soft.)


OpenALPauseResume uploaded at https://github.com/ewmailing/MyAppleBugs