描述问题

在使用MaryTTS时，如果技能使用speak_dialog并设置wait=True,或者依赖于该方法的其他方法，如get_response,语音播放将在语音结束之前不会等待，而是直接跳到下一个指令。后果取决于技能是如何构建的：对话可能会突然被音频提示开始录音打断，从而导致技能执行顺序混乱。或者，由于RemoteTTS(MaryTTS的超类)将长句子拆分，不同的语音部分重叠在一起，导致音频混乱。
我发现的问题是RemoteTTS(MaryTTS的超类)在其execute方法的定义中没有调用create_signal("isSpeaking"),而大多数其他TTS模块使用的是基本的TTS超类。因为"isSpeaking"没有设置，应该一直等到语音结束的等待循环立即结束。
在RemoteTTS的execute方法开头添加create_signal("isSpeaking")可以解决这个问题。此外，我认为扩展RemoteTTS而不是TTS的其他TTS模块也会受到影响。

重现步骤

重现行为的方法：

1. 配置TTS以使用MaryTTS
2. 使用一个要求用户响应的技能(或创建一个)
3. 您应该在Mycroft结束问题之前听到提示说话的声音

预期行为

当使用wait=True或像get_response、ask_selection等方法进行对话时，语音应在技能移动到下一个指令之前完成。

日志文件

如果有必要，我可以尝试提取一些日志，尽管我不得不手动向Mycroft /skills脚本添加一些额外的日志记录来弄清楚发生了什么。我也可以尝试提供一些音频录制。

环境信息

• 设备类型：树莓派4 Model B 4GB
• 操作系统：Picroft发布候选版v21.02.0_20210604
• Mycroft-core版本：v21.02.0
  附加信息

我已经将Mycroft配置为使用"marytts"作为TTS模块，但实际服务器并没有运行MaryTTS,而是运行OpenTTS,它可以作为MaryTTS客户端的替代品。服务器在笔记本电脑上运行测试，我使用的语音质量较高。这导致合成语音时出现明显的延迟，使得等待时间不足更加明显。对于非常短的句子和快速的服务器响应，这种bug的影响可能很容易被忽略。