OK, so this log says that listening has stopped at the end (I’m assuming that you’re logging “Pocketsphinx has stopped listening.” is called in the “pocketsphinxHasStoppedListening” delegate method), so stopListening is seemingly completing, which I think leaves the issue as not being able to restart after stopping, not that there is an issue with stopping. I think you’re correct that the issue is here:
2015-09-03 15:48:24.399 mathcommand[1655:498046] 15:48:24.399 ERROR: [0xd8de000] AVAudioSession.mm:646: -[AVAudioSession setActive:withOptions:error:]: Deactivating an audio session that has running I/O. All I/O should be stopped or paused prior to deactivating the audio session.
2015-09-03 15:48:24.400 mathcommand[1655:498046] Error: couldn't set session inactive.: '!act'
2015-09-03 15:48:24.415 mathcommand[1655:498046] Error: there was a problem tearing down the audio session: Error Domain=NSOSStatusErrorDomain Code=560030580 "The operation couldn’t be completed. (OSStatus error 560030580.)".
This means that Unity is still using audio IO although OpenEars isn’t, which is going to be the probable reason that recording doesn’t work again in the second start. There is an additional issue which appears early on in the logs, which is that Unity tries to reassert its own session settings after OpenEars sets them, which I would guess is negatively affecting recognition since neither 24k or 41.1k are sample rates that OpenEars can perform recognition with.
It is probably a requirement for normal usage of OpenEars that you learn how to shut down Unity’s audio IO before starting OpenEars and how to restart Unity’s audio IO after stopping OpenEars.
If you want to verify what is happening, you can now do a minimal session that shows starting, stopping, and then starting again, demonstrating the failure to start the second time. That may have some very informative logging out of OpenEars during the second start attempt.