HomeForumsOpenEars[Resolved] Problem with 1st utterance after changeLanguageModelToFile

This topic has 6 voices, contains 6 replies, and was last updated by  aerialcombat 152 days ago.

Viewing 7 posts - 1 through 7 (of 7 total)
Author Posts
Author Posts
July 29, 2011 at 6:38 pm #7420

darbienapp

For the SampleProject file I created multiple sets of ARPA language models and dic files. For example :
set 1 : YES, NO, MAYBE
set 2 : MONDAY, TUESDAY
set 3 : ONE, TWO, THREE

and I created 3 custom buttons so when pressed it will call changeLanguageModelToFile and switch to the corresponding model. It seems to work fine but I’m running into this problem that when ever I called changeLanguageModelToFile the next utterance is still using the old language model. For example if I’m in set 1, and I call changeLanguageModelToFile for set 2, the next speech I’m still getting results from set1. However all subsequent speech are correctly going into set 2.

The document seems to indicate that once I change the language model it will switch immediately, not after the next utterance. Also, I check for the log in “pocketsphinxDidChangeLanguageModelToFile” and it seems to indicate this behavior, that the 1st one after change is always using the old model, but after that it’s fine.

Do I need to do something differently to for the model chnage immediately?

July 29, 2011 at 9:20 pm #7421

Halle

Nope, it should work automatically. This might be a bug — the issue is that the idea of switching models when the user presses a button is a bit unexpected to me, since I designed it to be used as IVR (i.e. a perceived utterance is what causes a language model change, like when you telephone your bank and they give you logically branching options for utterances).

I think I need to do a round of testing in order to see what happens when a change is forced via non-speech UI in the middle of a still-in-progress recognition. Unfortunately I may not get to it that soon, we’ll have to see.

What will probably have to be done is to force a quick reset of the buffer and the loop when this command comes so that nothing more happens before the switch takes place. Sorry this isn’t quite working as hoped-for yet.

August 30, 2011 at 3:45 pm #7553

johnservinis

Hey there, I’m also using buttons and delays and things that go a little beyond the limitations of this brilliant API. Firstly a million thanks, Halle, for the effort you’ve put in and your generosity to share.
Darbienapp, and anyone else seeking to do similar things, what you are experiencing is this:
The continuousModel will calibrate, then check if there’s a request to change the LM, then sit indefinitely in a loop, waiting for input. You are clicking the button to change the LM, but its having no effect because its waiting for speech. The only thing that will invoke the LM change now is to say something, which will mean an incorrect and useless hypothesis based on the first LM.
What you want to do is go into the continuousModel.mm file and find the block that looks like this:

// Wait for speech and sleep when we don't have any yet.
while ((speechData = cont_ad_read(continuousListener, audioDeviceBuffer, maximumAndBufferIndices)) == 0) {
usleep(30000);
if(exitListeningLoop == 1) {
break; // Break if we're trying to exit the loop.
}
}
if(exitListeningLoop == 1) {
break; // Break if we're trying to exit the loop.
}

and change it to this:


// Wait for speech and sleep when we don't have any yet.
while ((speechData = cont_ad_read(continuousListener, audioDeviceBuffer, maximumAndBufferIndices)) == 0) {
usleep(30000);
if(exitListeningLoop == 1) {
break; // Break if we're trying to exit the loop.
}
if(thereIsALanguageModelChangeRequest == TRUE) {
break; // leave this 'waiting for speech' loop
}
}

if(thereIsALanguageModelChangeRequest == TRUE) {
continue; // go back to start of loop and invoke LM change on the way back to 'waiting' loop
}
if(exitListeningLoop == 1) {
break; // Break if we're trying to exit the loop.
}

This breaks the ‘waiting for input’ loop, then by calling continue, cycles back to the start of the main recognition loop and thus invoking the LM change on the way back.
Hope this helps anyone trying to do the same.

August 30, 2011 at 3:47 pm #7554

Halle

Nice, John, thanks for posting.

September 25, 2011 at 11:15 pm #7616

jscheller

Just ran into this as well and John’s changes fixed me right up… Many thanks!

November 17, 2011 at 6:44 am #8090

culov

Worked great for me too, thanks.

December 18, 2011 at 1:06 am #8252

aerialcombat

Had the same problem. Works wonderfully, thanks, John!

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

You must be logged in to reply to this topic.