RuleORama : Force SilenceDetection

Home Forums OpenEars plugins RuleORama : Force SilenceDetection

Topic Resolution: Resolved
Viewing 7 posts - 1 through 7 (of 7 total)

  • Author
    Posts
  • #1027109
    tbrandt78
    Participant

    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

    #1027113
    tbrandt78
    Participant

    Hey 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.

    #1027157
    tbrandt78
    Participant

    Hey 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,
    Tim

    #1027173
    Halle Winkler
    Politepix

    Hi 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.

    #1027177
    tbrandt78
    Participant

    Yes, I was indeed fooling myself.
    In this forum :
    https://www.politepix.com/forums/topic/savethatwav-not-respecting-secondsofsilencetodetect/#post-1027176

    I 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!

    #1027179
    Halle Winkler
    Politepix

    You’re welcome, and thank you for your even keel in the face of the challenges of speech-driven interface.

    #1027187
    tbrandt78
    Participant

    No 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.

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.