Home › Forums › OpenEars plugins › After first recognition failure, all successive attempts fail
- This topic has 9 replies, 2 voices, and was last updated 9 years, 4 months ago by Halle Winkler.
November 26, 2013 at 2:57 pm #1019002
I am using Openears + Rejecto. I have it set up to both send null hypothesis and send rejected words. All recognition works fine in my app until my first failure, after which piont i get log messages such as the following for any words whatsoever which were easily recognized before:
Pocketsphinx received a hypothesis is with a score of -6823 and an ID of 000000010
Why would this happen?
Here is my workflow:
1) Receive hypothesis
2) Suspend recognition
3) Handle recognized or unrecognized hypothesis
4) Resume recognitionNovember 26, 2013 at 3:05 pm #1019004
I don’t know a reason for this to happen offhand. Have you turned on the PocketsphinxController and OpenEars verbose logging tools to look at the detailed output?November 26, 2013 at 4:55 pm #1019010
Ok…it seems to only happen in the iOS 6.x simulator. No more simulator for me ever.November 26, 2013 at 4:59 pm #1019011
Heh, darn that Simulator. It probably has something to do with something particular about the buffer size on your local audio host device that is being emulated as an iOS mic.November 27, 2013 at 11:14 am #1019029
So, after further investigation I believe that this was related to reusing the same .dmp/.dic file multiple times. I have seen another forum post where the user reccommended alternating dictionary files but this does not resolve the issue.
The only thing resolving it for me is to use a new filename each time. How can I work around this because I’m making a game where this would result in hundreds of files.
To offer a little more potential insight into how this may have worked for the other user, it also seems to work if I alternate between dictionaries but ONLY as long as they never change their contents. Once a word changes then that dictionary becomes corrupt if I attempt to reuse it.November 27, 2013 at 11:40 am #1019030
I think this is just a Sphinx thing where the phonetic dictionary isn’t being changed since there is already a phonetic dictionary with that name, and then you have a phonetic dictionary with different work contents than the DMP (not corruption, but also not possible to make a match when a word is spoken). IIRC from past development in this area the API for changing a model set is a little more straightforward than the API for changing the phonetic dictionary contents and what I have in there might not be as resistant to unusual situations.
My recommendation for an approach that shouldn’t cause any user-apparent time overhead or file system clutter is just to have a method which appends an incrementing int to the end of the chosen file name and deletes the one with the previous int ending.November 27, 2013 at 2:23 pm #1019031
Ah, understood. This was quite difficult to figure out for me. I based my project on an older PhoneGap plugin for Openears that was on Github which is doing exactly what caused this problem. I think they are unaware of this limitation.November 27, 2013 at 2:34 pm #1019032
OK, that’s important troubleshooting info so please mention it early.November 27, 2013 at 2:36 pm #1019033
Never mind, I see that you told me about it in your other question — forget I mentioned it!November 28, 2013 at 8:57 am #1019035
I just wanted to check — are all of the different language models due to the fact that you have hundreds of unique vocabularies that you need to use in series in a single app session, or is that something related to the phonegap wrapper’s issues? I can imagine applications in which unique vocabularies were being constantly generated in such large quantities but it’s unusual. Usually developers have a number of language models in the single digits that they switch between without ever regenerating them after the initial creation.
- You must be logged in to reply to this topic.