I am developing an Android Application that is based around Speech Recognition.
Until today everything has been working fine and in a timely manner, e.g. I would start my speech recogniser, speak, and within 1 or 2 seconds max the application received the results.
It was a VERY acceptable user experience.
Then today I now have to wait for ten or more seconds before the recognition results are available.
I have tried setting the following EXTRAS, none of which make any discernible difference
07-01 17:50:20.839 24877-24877/com.voice I/Voice: onReadyForSpeech()
07-01 17:50:21.614 24877-24877/com.voice I/Voice: onBeginningOfSpeech()
07-01 17:50:38.163 24877-24877/com.voice I/Voice: onEndOfSpeech()
This is a bug with the release of Google 'Now' V6.0.23.***
Since the release of V5.11.34.*** Google's implementation of the
SpeechRecognizer has been plagued with bugs.
You can use this gist to replicate many of them.
You can use this BugRecognitionListener to work around some of them.
I have reported these directly to the Now team, so they are aware, but as yet, nothing has been fixed. There is no external bug tracker for Google Now, as it's not part of AOSP, so nothing you can star I'm afraid.
The most recent bug you detail pretty much makes their implementation unusable, as you correctly point out, the parameters to control the speech input timings are ignored. Which according to the documentation:
Additionally, depending on the recognizer implementation, these values may have no effect.
is something we should expect......
The recognition will continue indefinitely if you don't speak or make any detectable sound.
I'm currently creating a project to replicate this new bug and all of the others, which I'll forward on and link here shortly.
EDIT - I was hoping I could create a workaround that used the detection of partial or unstable results as the trigger to know that the user was still speaking. Once they stopped, I could manually call
recognizer.stopListening() after a set period of time.
stopListening() is broken too and doesn't actually stop the recognition, therefore there is no workaround to this.
Attempts around the above, of destroying the recognizer and relying only on the partial results up until that point (when destroying the recognizer
onResults() is not called) failed to produce a reliable implementation.