Open Radar

 
I'm one of the developers for Google Chrome, we've had a long standing issue where users have reported their audio stops working. See http://crbug.com/160920. We're seeing almost daily reports of this issue and internal metrics suggest > 3% of our OSX user population have hit this problem.

The root problem from Chrome's point of view is that AudioUnits which start "successfully" (i.e. AudioOutputUnitStart() returns noErr) never deliver any AURenderCallbacks. Once a system is in this state, any subsequently created AudioUnits will have the same problem.

The problem can be resolved by closing all outstanding AudioUnits or restarting coreaudiod; neither of which is a very attractive solution.

After some investigation I've managed to created a minimized test case. Please see the attached program.  The test program simply creates to AudioUnits, starts them, and then waits for the first AURenderCallback to come in, after which the units are stopped.

Through repeated suspend and resume (open/close lid on laptop) the program will hang after starting the AudioUnits while waiting for the first AURenderCallbacks.

Steps to Reproduce:
- Compile the included test case:
clang -framework CoreAudio -framework AudioUnit -lstdc++ audio-hang.cc

- Start the program via "./a.out", observe a repeated beeping pattern.

- Repeatedly suspend (close system lid) and resume (open system lid) the system until the beeping pattern stops.

- Observe that the program is stuck waiting for AURenderCallback events.


Expected Results:
Program should never hang.

Actual Results:
Program hangs waiting for AURenderCallbacks.

Version:
Seems to occur on all OSX versions from 10.6 to 10.9.

Notes:


Configuration:
Primarily observed on MacBook hardware; likely due to desktops not seeing as many suspend and resume events.

Attachments:
'audio-hang.cc' was successfully uploaded.

http://commondatastorage.googleapis.com/dalecurtis-shared/audio-hang.cc