Welcome Dave,
Thanks for your kind words. So, about #1, my perspective is that having a state boolean is good for things that might have an unknown state because they move from state to state on their own, but starting and stopping listening can only happen as a result of messages you send so that one is better for you to track in your view controller. But it sounds like you aren’t tracking the state based on whether you have started and stopped but based on whether you have started and then received a callback, which is maybe a case I’m not thinking of — can you elaborate on how you are using a callback to track the state with your boolean rather than setting it when you make a call to start or to stop? I’ve been thinking that PocketsphinxController needs to exit gracefully when it can’t access the mic due to being called twice in any case so that will probably be in a version coming out soon.
ERROR: [0x317d000] >aurioc> 783: failed ‘!pla’ (enable 3, outf< 1ch, 16000 Hz, Int16> inf< 1 ch, 16000 Hz, Int16>
That’s a new one for me, but I’ll admit that I focus the majority of testing on the foreground. I saw a similar description on SO, does it help?
http://stackoverflow.com/questions/19710426/avplayer-not-working-on-ipad-when-device-auto-locked
It looks like the audio session is being changed, which would make it hard for PocketsphinxController to work. Do you have a more verbose error to show me?
3) I notice that when OpenEars is listening while my app is active, I can no longer play the lock screen button sound when the button is depressed to lock the screen. If my app is backgrounded (stops listening) then the lock screen button sound plays fine. Is there any way to overcome this?
Sorry, no, this is due to a bug with the PlayAndRecord audio session that PocketsphinxController makes use of and system sounds.
I’m looking for a recommended approach to manage these issues.
In my experience it is a requirement to stop listening when there is an interruption and start listening after it ends. In addition to the technical requirements that make it difficult to support doing anything else, it is also a situation in which the external audio environment is very likely to change during the call, meaning that whatever the speech/silence calibration state was before the call, it probably won’t apply well afterwards meaning that it will probably take just as long for the VAD to catch up to the new circumstances and start giving relevant results again as it would to stop and restart with a new calibration. If you’re getting a crash when stopping once you get the interruption callback and starting once you get the interruption over callback and you are positive that you aren’t double-instantiating PocketsphinxController, that could be a bug although I did test this before the last release. In that case, can you show me the contents of those callbacks and I can take a look at it?