I am analyzing the incoming sound on the iPhone / iPod Touch using Audio Queue Services. The desired behavior of the analyzer is as follows: when the application becomes active, start the analysis; when the application is in the background, stop the analysis.
I use a direct approach, using AppDelegate to start and stop the analyzer each time the application state changes.
Here is the code:
- (void)applicationWillResignActive:(UIApplication *)application { AudioQueueFlush(_aqRef); AudioQueueStop(_aqRef, true); AudioQueueDispose(_aqRef, true); } - (void)applicationDidBecomeActive:(UIApplication *)application { AudioQueueNewInput(&_formatDescription, _renderCallback, NULL, NULL, NULL, 0, &_aqRef); AudioQueueAllocateBuffer(_aqRef, _aqBufferSize, &_aqBufferRef); AudioQueueEnqueueBuffer(_aqRef, _aqBufferRef, 0, NULL); AudioQueueStart(_aqRef, NULL); }
All variables are initialized and work - they take it as given and verified. Queue and buffers should not be deleted and allocated every time, I know, but so far it does not matter, and it is more complete.
Here's what happens:
Step 1) Launch the application, the audio lineup begins, Bob is your uncle.
Step 2) Press the power button and the application will pause. However, you do not hear a blocking sound, because the audio queue still blocks the sounds of the system. However, sometimes this appears, mainly after the first launch of the application, but it is unreliable. First glitch.
Step 3) Press the home button and unlock the phone. Again, you won’t hear the phone’s system unlock sound because the audio queue is already taken. However, you may hear a short unlock sound. Sometimes. Not reliable. The second failure.
Step 4) Press the home button and send the application in the background. About a second after the application disappeared, the system remembers that it could not play the unlock sound in step 3 and is playing it now. In full. This is very bad.
This leads me to two questions:
Question 1): When the power button is pressed, I see no other way to stop the audio queue earlier than in applicationWillResignActive :. Is anything missing here? I'm fine with a missing locking sound, but I'm glad to learn about any other way to make sound (or not sound) reliably.
Question 2): The delayed unlocking sound in step 4 gives me a headache. An easy way to prevent this would be to delay the start of the audio queue so that the unlock sound can be played back seamlessly. But that sounds like a hack, and if anyone could point me in a better direction, I would be a much happier coder.
Thanks / Andreas