Reply To: OpenEars crashes every time now I've upgraded to iOS6

Home Forums OpenEars PocketsphinxController plus Nuance SDK breaks AudioSessionManager in iOS6 Reply To: OpenEars crashes every time now I've upgraded to iOS6

#11294
Halle Winkler
Politepix

OK, since that means that it is something relating to code that I don’t have access to, let me explain what is weird in the logging and maybe it will point you towards what to check out.

Early on in the app session your category is set (correctly) the first time and we’d normally expect it to remain that way for the rest of the app session unless it is overridden by a call to audiosession or AVAudioSession or the use of a media object like AVPlayer or MPMoviePlayerController:

2012-09-25 15:38:46.061 test[819:907] audioCategory is now on the correct setting of kAudioSessionCategory_PlayAndRecord.

Then some very normal stuff is done to bluetooth, default to speaker, etc, with no errors returned. At this point the audio session settings look very normal and if an attempt were made here to start the audio unit I would expect it to work.

Then the device has some kind of DNS library issue which might be unrelated:

2012-09-25 15:38:46.194 test[819:907] [NMSP_ERROR] check status Error: 696e6974 init -> line: 318

However, if this is an automatic function of the Nuance SDK it is a sign that its objects might be instantiated at this point.

PocketsphinxController continues starting up and gets as far as it can without any errors before it needs to start the audio unit, which is when things get weird:

2012-09-25 15:38:46.407 test[819:907] Audio route has changed for the following reason:
2012-09-25 15:38:46.408 test[819:907] There has been a change of category
2012-09-25 15:38:46.409 test[819:907] The previous audio route was SpeakerAndMicrophone
2012-09-25 15:38:46.535 test[819:907] This is not a case in which OpenEars performs a route change voluntarily. At the close of this function, the audio route is Speaker
2012-09-25 15:38:46.536 test[819:907] Audio route has changed for the following reason:
2012-09-25 15:38:46.541 test[819:907] There has been a change of category
2012-09-25 15:38:46.542 test[819:6607] Set audio route to Speaker
2012-09-25 15:38:46.542 test[819:907] The previous audio route was MicrophoneBuiltIn
2012-09-25 15:38:46.544 test[819:6607] Checking and resetting all audio session settings.
2012-09-25 15:38:46.545 test[819:907] This is not a case in which OpenEars performs a route change voluntarily. At the close of this function, the audio route is Speaker
2012-09-25 15:38:46.546 test[819:6607] audioCategory is incorrect, we will change it.
2012-09-25 15:38:46.782 test[819:6607] audioCategory is now on the correct setting of kAudioSessionCategory_PlayAndRecord.
2012-09-25 15:38:46.786 test[819:6607] bluetoothInput is incorrect, we will change it.
2012-09-25 15:38:46.791 test[819:5c03] 15:38:46.792 shm_open failed: “AppleAURemoteIO.i.724ba” (23) flags=0x2 errno=2
2012-09-25 15:38:46.795 test[819:5c03] 15:38:46.795 AURemoteIO::ChangeHardwareFormats: error 3
2012-09-25 15:38:46.796 test[819:5c03] 15:38:46.797 shm_open failed: “AppleAURemoteIO.i.724ba” (23) flags=0x2 errno=2
2012-09-25 15:38:46.797 test[819:5c03] 15:38:46.798 AURemoteIO::ChangeHardwareFormats: error 3
2012-09-25 15:38:46.805 test[819:6607] bluetooth input is now on the correct setting of 1.
2012-09-25 15:38:46.808 test[819:6607] categoryDefaultToSpeaker is incorrect, we will change it.
2012-09-25 15:38:46.808 test[819:907] Audio route has changed for the following reason:
2012-09-25 15:38:46.810 test[819:907] There has been a change of category
2012-09-25 15:38:46.811 test[819:907] The previous audio route was Speaker
2012-09-25 15:38:46.893 test[819:6607] CategoryDefaultToSpeaker is now on the correct setting of 1.
2012-09-25 15:38:46.895 test[819:6607] preferredBufferSize is correct, we will leave it as it is.
2012-09-25 15:38:46.897 test[819:6607] preferredSampleRateCheck is correct, we will leave it as it is.
2012-09-25 15:38:46.896 test[819:5c03] 15:38:46.896 shm_open failed: “AppleAURemoteIO.i.724ba” (23) flags=0x2 errno=2
2012-09-25 15:38:46.898 test[819:6607] Setting the variables for the device and starting it.
2012-09-25 15:38:46.900 test[819:6607] Looping through ringbuffer sections and pre-allocating them.
2012-09-25 15:38:46.895 test[819:907] This is not a case in which OpenEars performs a route change voluntarily. At the close of this function, the audio route is SpeakerAndMicrophone
2012-09-25 15:38:46.899 test[819:5c03] 15:38:46.899 AURemoteIO::ChangeHardwareFormats: error 3
2012-09-25 15:38:46.907 test[819:907] Audio route has changed for the following reason:
2012-09-25 15:38:46.908 test[819:907] There has been a change of category
2012-09-25 15:38:46.909 test[819:907] The previous audio route was ReceiverAndMicrophone
2012-09-25 15:38:47.497 test[819:6607] Started audio output unit.
2012-09-25 15:38:47.499 test[819:907] This is not a case in which OpenEars performs a route change voluntarily. At the close of this function, the audio route is SpeakerAndMicrophone

I count 4 category changes and 4 route changes resulting from it, all in approximately one second. That seems like something trying to override the OpenEars settings in an automatic way. You can see that at the moment that the audio unit begins, it isn’t set to a category which has a recording input, because the next thing that happens is that OpenEarsLogging announces that there was a route change to a route that contains a recording input (the last line above). The fact that the audio unit is trying to start at a time in which it seems like it has a mic input, then it disappears while the unit starts, is probably the origin of the crash.

Are you completely positive that there is nothing going on with your Nuance SDK at the time that PocketsphinxController has started? Because that would make a lot of sense as the source of objects which are listening for audio session changes and automatically reacting to them. Otherwise, do a case-insensitive search of your app for “audiosession” and see if there are any AudioSession or AVAudioSession calls made by the app. You might also want to look for AVPlayer, AVAudioRecorder and/or MPMovieController objects (or other objects that assert their own audio session settings) that are instantiated at that time. I will keep looking into it in the meantime so please let me know if you find a cause in your app.