-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibility to turn off trigger detection within settings.yml #325
Comments
And why it's a big deal to let it start anyway? |
If server / client infrastructure is available users will probably ask for it as Kalliope is used as a backend which is meant to return answers only or initiate some actions like home automation. The issue sone of us observed with stability of Kalliope on some systems has a good workaround but probably was due to concurring audio where in my case Kalliope audio should be redundant. I didn't wrote that it's a big deal or should have a high or even medium priority, only that waiting for a hotword trigger is redundant if there will definitely no one. I was not considering any CPU resources which Snowboy consumes here, i don't think that it's of any significance. |
@1account would this feature answer your need? |
I think not. Muted means that kalliope will not speaks out loud when processing a neuron. Here, the feature is to disable the trigger process (snowboy). |
Isn't it what mute does (put snowboy process on pause) ? if muted:
self.trigger_instance.pause()
self.is_trigger_muted = True
Utils.print_info("Kalliope now muted") I guess it doesn't disable it per say though :) FWIW: I worked on #376 via this PR if it's "enough" for now (as I think this real "disable snowboy" will only happen when moving to the server/client architecture) |
@1account I think the last feature made by @bacardi55 should be what you wanted. Hope it help anyway. Tell us if we can close this issue. |
For those who use Kalliope with REST API only trigger detection / hotword detection makes no sense at all, this holds for a planned server / client infrastructure too, see #228
The text was updated successfully, but these errors were encountered: