After first recognition failure, all successive attempts fail

[Lann]

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 recognition

[Halle Winkler]

Hi Lann,

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?

[Lann]

Ok…it seems to only happen in the iOS 6.x simulator. No more simulator for me ever.

[Halle Winkler]

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.

[Lann]

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.

[Halle Winkler]

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.

[Lann]

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.

[Halle Winkler]

OK, that’s important troubleshooting info so please mention it early.

[Halle Winkler]

Never mind, I see that you told me about it in your other question — forget I mentioned it!

[Halle Winkler]

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.

[Author]

Posts