Topic: Kill voice recognition thread : Politepix

This topic has 4 voices, contains 10 replies, and was last updated by Halle 51 days ago.

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

Author	Posts
Author	Posts
January 12, 2012 at 12:26 am #8386
culov	I have an issue where occasionally, the voice recognition thread is going on for 10+ seconds. Everytime, this is a mistake — the user is not intending to speak to the device — so i want to cancel that thread. I’ve tried stopVoiceRecognitionThread to no avail. Is there anything else I can try?
January 12, 2012 at 8:36 am #8387
Halle	This is a bug if it isn’t due to a configuration issue. Rather than trying to kill the thread, it would be more helpful to troubleshoot why you are getting such unexpected behavior. What is OPENEARSLOGGING/VERBOSEPOCKETSPHINX reporting at those times, what OpenEars version are you using, what device and with what OS? Is there something else going on in your app that could be interacting with this, perhaps by causing the audio session to be altered? This is the first report of this kind of behavior I’ve ever heard so it would be good to see if it can be replicated. Are you using the Apple GCC or Apple LLVM compiler? BTW, as it says in the interface, stopVoiceRecognitionThread isn’t intended to be a public method and it will not be able to handle exiting the loop for you when called directly. Stopping recognition is done via stopListening. If stopListening doesn’t work, you are experiencing a bug that will prevent safe exit from the loop by other means.
January 14, 2012 at 5:08 am #8402
culov	Hi Halle, It’s only a problem for me because my users are occasionally in a noisy environment — sometimes for a protracted amount of time. The idea was to restart the thread because once they escape the very noisy environment, either the app has crashed for it being in that area too long, or the returned audio file takes a very long time to process. I would recalibrate, after x seconds, but I’m not sure that would be any better than it is now. Thanks
January 14, 2012 at 10:32 am #8403
Halle	There’s no inherent reason that the app should crash due to listening. If you see a crash, it would be good to show me the logging from OPENEARSLOGGING and VERBOSEPOCKETSPHINX that precedes it. stopListening will exit the thread (any other method of exiting the thread will also shut down the recognizer so there is no reason not to use stopListening). There isn’t currently any code in the loop that will let you exit the innermost listening loop without exiting the outer recognition loop.
March 26, 2012 at 7:17 pm #9065
hartsteins	I am interested in this as well. User is occasionally in a noisy environment and the listener essentially gets held up trying to make sense of the background noise. Is there any way to add some sort of timer to stop listener from trying to recognize after a set interval? Very often a clean “1 sec of silence” (or shorter) does not occur. It feels like a setting change in “AudioConstants.h” might do this but I am not sure what to adjust. Alternatively I guess I could add my own timer and “suspend/resume” recognition. I’d prefer not to fully stop & start listening as the restart takes more time than makes sense to do repeatedly. Thanks for the help and great library Greg
March 26, 2012 at 8:58 pm #9078
hartsteins	So as an work-around fix I added a timer that stops/starts recognition at a set interval after “earsControllerDidDetectSpeech” . If “earsControllerDidDetectFinishedSpeech” comes in, the timer is canceled. The only problem is the time it takes for re-calibration to occur. Is there any way for suspend/resume to reset the recognition thread or is start/stop the only way? If stop/start is the answer…is there a way to cut down calibration time (or save old calibration state)? thanks again again Greg
March 26, 2012 at 9:04 pm #9079
Halle	1.0 has an option for way faster calibration, and calibration time can be set from three different options in OpenEarsConfig.h. It’s also generally faster due to llvm optimization (when you run it in release mode).
March 26, 2012 at 9:17 pm #9084
hartsteins	Hmmmm…..perhaps a move to 1.0 is needed after all. The options in OpenEarsConfig.h are new right? continued thanks Greg
March 26, 2012 at 9:20 pm #9085
Halle	Yep, OpenEarsVoiceConfig.h is gone and its settings moved into OpenEarsConfig.h, and there are some new options in OpenEarsConfig.h and some of the old options have been made runtime properties. Everything is in a single downloaded framework now, so adding it is basically dragging the framework in and then making your code changes to match the framework changes. No more config script, separate dependency downloads, Objective-C++, etc. But you will need to make some changes in how you add headers, little API differences, etc.
March 27, 2012 at 10:50 pm #9096
Joseph S. Wisniewski	> There’s no inherent reason that the app should crash due to listening. There’s a math error in Sphinx that can cause crashes in noise whenever there’s a “loop” in a FSG, or whenever you’re using a language model, because Sphinx triphone models always loop. I’ll see if I can get clearance to post it.
March 28, 2012 at 4:41 pm #9118
Halle	Have you seen it in OpenEars? I discovered a crashing issue under similar circumstances about a year ago but I did find and include a workaround. I’d certainly be interested in knowing about another one. I understand why someone wouldn’t want to get stuck in a long recognition (for me it sometimes happens on account of cheeping sparrows outside my window) but I’d prefer that worrying about crashing not be among the reasons for it.