[Resolved] App crash when reopening view that use openears

This topic has 2 voices, contains 2 replies, and was last updated by Halle 88 days ago.

Viewing 3 posts - 1 through 3 (of 3 total)

Author	Posts
Author	Posts
February 20, 2012 at 8:33 am #8658
Oldfield	I have a view (.mm) that instances a OpenEarsEventsObserver PocketsphinxController in an identiacl manner to the Sample project. It deallocates these objects in an identical manner to the sample project. When the view is first opened it all works fine. If the view is closed an re opened then there are mutilple thread errors. I know this is NEWBE question and that I am being stupid somewhere, however, can you please help
February 20, 2012 at 9:04 am #8659
Oldfield	OK I found the fix. The next thing I tried was to call the stopListening method in my IBAction that closes the current view. I use an action here because I am using a page curl animation to move between views. Here is the code with the line that fixed my problem - (IBAction) closePage:(id)sender { //this stop the listener and prevent any thread errors [pocketsphinxController stopListening]; [UIView beginAnimations:nil context:NULL]; [UIView setAnimationDuration: 1]; //setting animation for the current view [UIView setAnimationTransition:UIViewAnimationTransitionCurlDown forView:self.navigationController.view cache:YES]; [self.navigationController.view setAlpha:0.2]; [self.navigationController popViewControllerAnimated:YES]; //Start the Animation [UIView commitAnimations]; } May I add I love this tool, it is great code and so well supported. CONGRATULATIONS!!!!
February 20, 2012 at 12:20 pm #8660
Halle	Thank you! I’m glad that you found the fix. You’ve figured it out, but for future readers of this issue, if you start up your PocketsphinxController on view load, make sure you stop it when you pop the viewController so that you don’t have two instances of PocketsphinxController trying to coexist when the view is next opened, since the various notifications and delegate methods that the internals pass around to will hit both instances near-simultaneously and cause lots o’ weirdness. That isn’t really a newbie mistake, it’s a reasonable one to make and moreso as developers move to ARC and expect to do less active management, but with the tight timing and threading in the driver and the engine loop and the VAD that lets the recognition speed perform well it’s a no-go to turn them all into race conditions between two threads. stopListening is designed to always put everything away carefully regardless of the reason for stopping the loop and it is never necessary to directly manage the threads beyond using stopListening on the thread in which you instantiated the PocketsphinxController. Any time you see a crash, it’s very probable that OPENEARSLOGGING and VERBOSEPOCKETSPHINX will show the origin — in this case it would have probably shown two attempted starts of pocketsphinx in some way or another. In the case of crashes due to unavailable TTS it will complain that the voice isn’t uncommented in the config.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.