Audio Recording AudioQueueStart freeze/delay (w/changing Audio Session category)

Originator:ewmailing
Number:rdar://10508829 Date Originated:2011-11-30
Status:Open Resolved:
Product:iPhone SDK Product Version:5.0
Classification:Other Bug Reproducible:Always
 
Summary:

To save you time, this is a duplicate of bug 9948362. This is a regression bug (introduced in iOS 5.)

This bug causes a 1 to 5 second freeze calling AudioQueueStart to do audio recording. From my experiments, I believe it related to changing the AudioSession category between recording->playback->recording. If I record, playback the recording, and do a recording, all subsequent recordings exhibit the delay.  Changing our AudioSession category to PlaybackAndRecord at startup and never changing the category seems to avoid the problem which makes me believe this is related to the changing the audio session category.

I believe this is a regression bug that was introduced in iOS 5.0. It is still present in 5.1 beta 1. It only appears reliably on some devices though. I reproduced the problem on a 4th gen iPod touch with 5.1 beta 1 and reproduced it on an iPhone 4 with 5.0.1. I also have a pretty reliable tester telling me it happens with iOS 5.0 on a 3GS. I am having problems reproducing it reliably on an iPad 2 running 5.0.1. I have seen it appear twice on an iPad 2, but it is not consistent. But it is always consistent with the iPhone 4 and iPod touch.


It seems that others have also found this problem, e.g.:
http://stackoverflow.com/questions/7757739/in-ios-5-after-the-category-changed-audioqueuestart-used-3-5-seconds-to-st

We are doing this in the Corona SDK which is used by many developers. I have several developers complaining about this problem. Unfortunately, the workaround of changing the audio session category to PlaybackAndRecord is not something I can put into Corona because it will negatively impact all our users not doing audio recording.

So to me, I interpreted Apple's docs to claim that for best performance and best interoperability with other apps that might be running in the background, you should pick the audio session category sparingly to use audio only when you need it. On the performance side, Record vs. PlaybackAndRecord was much better (at least with earlier hardware/os's) because the PlaybackAndRecord couldn't utilize the hardware decoder for playback or recording.

If I recall, Apple's own recording example used to change the category between Record(only) and some playback mode when recording a sample and playing it back. Our demo app does something similar. I believe Apple's sample also disabled and enabled the AudioSessionSetActive when needed. Presumably this could allow background apps (iPod) to play until you actually needed the audio service. And we don't set PlaybackAndRecord because of efficiency issues (we still support 3.1 devices) and our demo doesn't need simultaneous playback/record.



Steps to Reproduce:

Since this bug is a duplicate, I really hope you already have a reproducible test case. My code is closed source and huge so I can't easily submit it. If you need a binary, you can download the Corona SDK and build for iOS using our SimpleAudioRecorder sample project that comes with the download. I would be happy to provide a test account and more detailed instructions. (I can also supply the binary without you needing to get Corona.)

But basically, my code does:
Set the audio session category to record.
Record via Audio Queue Services
Stop recording
Change audio session category to playback (soloambient I think)
Play back the recording (via OpenAL)
Stop playback.
Repeat sequence and the delay appears on the start recording for all subsequent repeats.


Expected Results:
Should not freeze/delay when starting a recording via AudioQueueStart.


Actual Results:
1-5 second freeze/delay when starting a recording via AudioQueueStart.


Regression:
This first appeared in 5.0 and is still present in 5.1 beta 1. 

However, I recall there was a bug very similar to this in iOS 3.1. I never filed a bug report because 3.2 or 4.0 had already fixed it by the time I discovered it. I believe it affected only the slower devices of that era at the time.



Notes:

If you can suggest an alternative workaround, I would appreciate it. Currently, I think I can make my users put a workaround into their own apps which might be sufficient, but they also need to do the iOS 5 version checks until it gets fixed which is hard to support from a Q/A standpoint.



Also one of my users has filed bug id: 10501739

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!