Home › Forums › OpenEars plugins › RuleORama : Force SilenceDetection
- This topic has 6 replies, 2 voices, and was last updated 7 years, 4 months ago by tbrandt78.
-
AuthorPosts
-
October 26, 2015 at 8:14 pm #1027109tbrandt78Participant
Hi Halle –
Again, amazing plugins! They have enabled us to do great things. We are just trying to fix some remaining issues in our app.
One thing, I recently switched to RuleORama to detect $COMMAND $USER phrases in my app such as ‘TEXT HALLE’ ‘CALL HALLE’, etc.
I first implemented this using RapidEars’ openEarsDidReceiveRealtimeHypothesis, but I found that it was so quick to guess the hypothesis, it always guess the same $CONTACT name from the phrase.So, we switched to using OpenEars’ openEarsDidReceiveHypothesis and it works outstanding for the most part, except when silence detection isn’t triggered.
About 15% of the time, the listener hangs for a really long time until silence detection is triggered.But, here’s the thing. By using RapidEars’ openEarsDidReceiveRealtimeHypothesis, I know when a phrase has been spoken. I would like to use that to force silence detection for cases when it doesn’t trigger, automatically. Is there a way for me to do so?
Tangentially, we are also using OpenEars to dictate a message and SaveThatWav to store it when the user is done. We also notice that for about 15% of the time it continues listening after the user has spoken because silence detection has not been triggered. So, that is a similar issue that we are having with OpenEars. Any advice that you have for that issue would be helpful, as well.
Thanks so much for your continued support!
-Tim
October 27, 2015 at 12:12 am #1027113tbrandt78ParticipantHey Halle –
Just a quick followup. So, I tried my suggestion and I set secondsOfSilenceToDetect to 0.f when RapidEars has a valid hypothesis for a command. I released a build and so far it’s working. We haven’t seen any hangs. I imagine that it does indeed force silence detection.
I will keep you updated, thanks.
November 2, 2015 at 11:37 pm #1027157tbrandt78ParticipantHey Halle –
This ‘trick’ seems to be working for us, for the most part. Just hoping to hear some confirmation from you on whether or not this is the way to go.
Thanks,
TimNovember 3, 2015 at 9:59 am #1027173Halle WinklerPolitepixHi Tim,
I don’t know what the results of that approach are likely to be, sorry. secondsOfSilenceToDetect settings of less than .09 are discarded and the default restored, so your improved results may be due to something else.
November 3, 2015 at 10:13 am #1027177tbrandt78ParticipantYes, I was indeed fooling myself.
In this forum :
https://www.politepix.com/forums/topic/savethatwav-not-respecting-secondsofsilencetodetect/#post-1027176I realized that secondsOfSilenceToDetect only take affect when starting the listener, anyway. So, I was probably experiencing the placebo effect.
My current thought is to cache the RapidEars result and if the regular OpenEars hypothesis does not kick in within a given threshold, just use it.
That should accomplish the same objective.Thanks again for all the help and the outstanding plugins.
I am just dialing in some details on an MVP that I hope takes us places.Thanks again!
November 3, 2015 at 10:43 am #1027179Halle WinklerPolitepixYou’re welcome, and thank you for your even keel in the face of the challenges of speech-driven interface.
November 3, 2015 at 7:09 pm #1027187tbrandt78ParticipantNo worries at all. These plugins work great.
I have just been figuring out the best way to use them for our purposes.
I think that we’ve gotten things pretty good.Thanks for your support and responses.
-
AuthorPosts
- You must be logged in to reply to this topic.