Does Josh’s suggestion work for you? Of the two issues you are showing, the first one in which the audio session is reset is 100% correct behavior — it means that PocketsphinxController detected that AVPlayer overrode the audio session settings and didn’t return them to their previous state at the right point in the loop, so it is doing so before it tries to start input recording. There’s no problem there. This one is the only problem:
<0x2bfc000> AURemoteIO::ChangeHardwareFormats: error 2
That means that at some point the switch back to the audio settings required by Pocketsphinx isn’t successfully instantiating the audio unit so no further audio input is going to be available. Josh’s advice sounds good to me as a workaround for this issue, which is probably related to the close timing between restarting listening and the amount of things that have to be done with the audio session and audio unit in order to recover from AVPlayer’s override.