Forum Replies Created
The sequence would be as follows:
1) Call startListening
2) Receive delegate message pocketsphinxRecognitionLoopDidStart, but did not yet receive a delegate message pocketsphinxDidStartListening (so we are in the middle of the startup process)
3) an interruption occurs while in the middle of this startup process at precisely the correct time – a crash occurs. I have not received any delegate message about an interruption occuring, so I have not called stopListening.
I have been focused on another project the last few days, but expect return to this soon and I will be able to do more testing.
I guess the larger question is, “what happens if Pocketsphinx is in the middle of executing a startListening cycle and the audio session suddenly becomes unavailable – was available at the start of the call (recogniton loop started) but has not yet started listening and before start listening completes (pocketsphinxDidStartListening not yet called) the audio session becomes unavailable.
Does your code handle this gracefully, or is there some period of time during the startup cycle where a resource is assumed to be there and if it suddenly disappears, the situation can cause a crash?
I realize this is kind of nit-picky for a lot of use cases; I’m just trying to ensure that my app handles this scenario as gracefully as possible. It seems that once the crash occurs, I am no longer able to receive a delegate message when the session becomes available again.
I will work on getting you better information in a couple of days.
Hi Halle, another question related to my study – If Pocketsphinx is starting up (received delegate message from pocketsphinxRecognitionLoopDidStart) but did not yet generate a pocketsphinxDidStartListening delegate message and suddenly, an audioSessionInterruptionDidOccur message comes through in the middle of initialization, is this situation managed in your code?
Overall, I have things working really well, but it seems that if an interruption occurs at just the right time during initialization, it crashes. I have not yet experimented with wrapping the startup in a try/catch clause, as this creates an efficiency hit, but if there is no better way to manage unexpected changes in audio route while in the middle of initialization, I will try this. Please advise.
Hi, some quick follow-up. It appears that I can manage all the issues I described relative to route changes due to phone calls with AVFoundation AVAudioSessionRouteChangeNotifications, which seem to work regardless of whether my app is backgrounded or foregrounded.
Your delegate methods appear to only work in the foreground (because they come from the main thread), so when my app is backgrounded due to an incoming call, I don’t get a route change notification that I can act upon.
By checking for 1) reason for route change and then 2) getting current input and output and 3) checking [[AVFoundation sharedInstance] isOtherAudioPlaying] before calling startListening, it seems that I can manage everything except the lock button sound issue.
I’m still optimizing and tuning, so I’ll confirm the final results, but it appears I don’t need to use an out-of-API call to make this work.
Hi Halle, Thanks for your response. I plan to experiment a little more with this before providing a detailed response, but thought I’d offer the following per your response now:
I ended up using 2 state booleans, one to track calls to start / stop listening and one to track responses from the callback (didStartListening, isListening).
I did this, because in my app, the user might background / foreground the app at any time, so if startListening has been called once, I wanted to avoid calling it again, regardless of confirmation from the callback. Same with stopListening. I use a combination of the state booleans to determine if/when it is appropriate to call again, based on app in foreground / background or audioSessionInterruptionDidBegin / End.
The crash issue appears to be a cause of the following sequence:
1) PocketsphinxController is listening in the foreground and working correctly.
2) App is backgrounded and stopListening is called.
3) A phone call is made. While call is in progress, my app is moved to foreground (voice recognition is an enhancement, not a requirement for my app to work).
4) Start listening is called because app is in foreground, but the error occurs because the phone call has control over the audio session.
So, what I am exploring is a way to determine through AVFoundation notifications when another app or the phone has control of the audio session and avoid a startListening call, but trigger that call if my app is in the foreground and all other apps have released control of the audio session.
The AVFoundation notifications are a new area for me, so I’m hoping that I can use them to determine when PocketsphinxController can successfuly assume control of the audio session.
Does this make sense? Any other observations on your part? Except for this audio session management issue and the lock screen button sound issue I described earlier, PocketsphinxController works fantastic and stopping / starting works fine relative to backgrounding / foregrounding my app.
I will follow-up with the results of my investigation / testing.