weixin_39969448
weixin_39969448
2021-01-12 03:33

Ability to play error sound instead of long error utterance

==== Fixed Issues ==== issue-2755 - Ability to play short error sound instead of long error utterance

==== Tech Notes ==== Add a new method parameter in the speak method for skills to declare if an utterance is an error. Add a new error sound. I have no skills in the domain, so it's quite horrible, sorry. It's the wakeword sound, reversed. Add two new configuration parameters for customizing Mycroft behavior when an error occured (per skill, or global) Change some TTS because I changed the tts execute signature : they overrode a method they should not, in my opinion. If my guess is good they should override the inner _execute method and not the main one. I could need some educated guess from the reviewer for this point. Technical note : The sound is played in the TTS module. It could be played upper in the stack but I did this in order to keep the functionality close to its replacement.

==== Documentation Notes ==== Two new parameters can force Mycroft to do error feedback with a brief sound instead of a complete error utterance : skills.skills_with_sound_as_error : a list of skills who should use sound. Use the class name. error_as_sound : boolean to force Mycroft to use sound for error feedback, wherever it is possible.

==== Localization Notes ==== NONE

==== Environment Notes ==== NONE

==== Protocol Notes ==== NONE

Description

fixes #issue-2755

How to test

Modify a skill (for example, fallback-unknown), to add a "is_error" parameter to the speak or speak_dialog method self.speak_dialog('unknown', is_error=True) Activate the replacement sound for this skill, either by the global configuration parameter (error_as_sound) or by white listing the "UnknownSkill" in the parameter skills.skills_with_sound_as_error Make mycroft says this dialog by asking him something nonsensical. Instead of the unknown dialog, Mycroft should play the error sound.

Contributor license agreement signed?

CLA [X]

该提问来源于开源项目:MycroftAI/mycroft-core

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

9条回答

  • weixin_39562998 weixin_39562998 4月前

    I was wondering if a simpler solution could be to have a special method in skills

    python
        def report_error(self, dialog, data):
            if _should_play_error():
                wait_while_speaking()
                play_wav(error_wav) # where error_wav is found somehow :)
            else:
                self.speak_dialog(dialog, data)
    

    It's simpler but not as nice as your version, enqueuing the error sound in the tts playback queue like that.

    I also wonder if we'd want a similar method as above with your changes to give a nice wrapper that just calls speak_dialog with the error flag set.

    点赞 评论 复制链接分享
  • weixin_39969448 weixin_39969448 4月前

    No problem, I let you (or other experienced mycroft developer) decide what is best, between simplicity or use of the playback queue mecanism. Just tell me what to do and I will be happy to commit some modifications (or you can do it yourself if you rather ; I'm not very knowledgeable of the usual process ?)

    点赞 评论 复制链接分享
  • weixin_39822629 weixin_39822629 4月前

    Hey, thanks for this great PR. This is an area that I think will expand significantly over time and it would be great to provide Skill developers with a range of consistent sounds to help users understand the outcome of their queries.

    The most direct example would be a "success" sound. Though I can also see use cases for things like: - action taken eg sound increase or decrease on the Mark 1 - adding or removing things from a list - more subtle than success and whilst both actions are considered successful, they are two distinct actions - turning on some {thing} - email sent - etc

    I also like the option for users to force the short response, however I think the by-product of this will be more Skills using the short sounds instead of dialog.

    At the moment I'm leaning toward a new method rather than adding an argument primarily because it can be used without dialog and still make logical sense. Eg when used with dialog it seems roughly equivalent:

    
    self.speak_dialog(dialog, data, is_error=True)
    self.report_error(dialog, data)
    

    However when used to intentionally only play the error sound it would be either:

    
    self.speak_dialog(None, is_error=True)
    self.report_error()
    

    An alternative would be to have a single method, something like:

    
    report_outcome(type="error", dialog, data)
    
    点赞 评论 复制链接分享
  • weixin_39822629 weixin_39822629 4月前

    I've just started a poll on the forums and chat to get a sense of how other dev's would prefer to trigger this sort of thing: - https://community.mycroft.ai/t/short-sound-to-indicate-error/9750 - https://chat.mycroft.ai/community/pl/h5fcozioki8nppxduyunscmjko

    点赞 评论 复制链接分享
  • weixin_39631017 weixin_39631017 4月前

    How about a self.sound(type='error') that would echo the existing self.speak(), and clearly keeping sound and speech separated and up to the developer to decide which he wants, or even combine? Or even possibly self.sound.confirm(), self.sound.error(), ..., a bit like self.log.info() and self.log.warning()

    点赞 评论 复制链接分享
  • weixin_39747807 weixin_39747807 4月前

    Probably an additional backend for "regular" logs would be an alternative, so aside of file logging, allow to set an optional log level (none/off by default) for "acoustic" log output, with a flag to either give a signal sound only or speak the error log text. So regular logging is done as before, and it's up to the admin to enable acoustic log notification or even spoken log entries.

    The bonus is that errors of mycroft-core can be made acoustic as well, as currently in cases there is no feedback at all when some internal error happened. The downside is that this does not allow developers to force that generic error output. Also Python error trances and such would need to be excluded, to not have it speaking code, so only the log text string.

    点赞 评论 复制链接分享
  • weixin_39643338 weixin_39643338 4月前

    I've fooled around with "multiple" sounds in the past, and it was pretty fun. I never got anything in a PR-able state, but I had an error sound, a cancellation sound, and a success sound, in addition to the wake sound.

    So I'm just here to +1 that idea.

    点赞 评论 复制链接分享
  • weixin_39822629 weixin_39822629 4月前

    the self.sound() is an interesting one, and perhaps something that should also get added. What I like about having the speech and sound explicitly combined is that in the future we could do some more intelligent decisions around which type of response makes the most sense in that situation.

    Some quick examples that come to mind are: - a user has explicitly defined a preference - the physical context of where a device is deployed makes one or another more appropriate - newer users might need more verbose output, but don't need to hear the same thing over and over again.

    点赞 评论 复制链接分享
  • weixin_39643338 weixin_39643338 4月前

    How about:

    • A tone for the wake sound
    • A lower tone for STT returned "silence"/on dismissal
    • A higher tone for STT success
    • Speak "I don't understand" on complete intent failure
    • A buzz for "an error occurred in X skill" and set a shortish-lived flag for thatSkill.recent_error
    • Speak "An error occurred..." if the same skill raises an error while the flag is set
    点赞 评论 复制链接分享

相关推荐