SpeakHere audio recorder crash after application comes foreground

1k Views Asked by At

I write a small audio recorder/player to use on my iPad, based on SpeakHere audio application example from Apple. When the user asks to display the recorder, a UIView opens and displays the record/stop buttons and the meters.

When I load application from scratch, I can record, stop the record, record again any times I want. After stopping the recording, I then put the application in the background, for example to read my mail. When putting the audio recorder foreground again, it is impossible to record any sound. I got an error message in my log, the meter do not display any data, and no sound file is created. I noticed the same behavior with the SpeakHere sample application, either on iPhone and iPad. The only solution is to quit and restart the application.

To deal with that, I decided to dealloc the view controller when the user has finished using the recorder. I disabled ARC for the record view controller, and wrote its dealloc method. The in the viewDidDisappear of this controller, I put a [self dealloc] call.

But the program crashes, sending a [RecorderViewController childViewControllersCount]: message sent to deallocated instance. I suppose that such an self-dealloc is not allowed...

I need to find a solution, either...

  1. Find a way that the audio session is properly managed when application goes to background (as recording is stopped, I don't understand why there is such a problem).

  2. Or properly deallocate the recorder view controller when its view is closed to ensure that any time the view must appear, it is loaded again from the controller's XIB file.

[UPDATED] After looking in the code of aurioTouch application (another audio example for Apple dev website), I went up with the following code in my application delegate:

- (void)applicationDidBecomeActive:(UIApplication *)application
{
    AudioSessionSetActive(true);

}

And it works, either in my application or in SpeakHere application... Spent hours to find a workaround, and it was one line of code!

0

There are 0 best solutions below