分析我的问题。
盲人使用屏幕阅读器与应用程序交互。这些屏幕阅读器以首选语速和其他设置朗读内容、消息等。从开发人员的角度来看，还有一些方便的功能：当将文本传递给屏幕阅读器时，它可以是自信的（所以打断屏幕阅读器）或礼貌的（屏幕阅读器完成当前文本的阅读，然后再进入下一个文本）文本）。
然而，一些盲人（或聋盲人）额外或单独使用盲文显示器。盲文显示器（理想情况下）显示屏幕阅读器正在阅读的文本或其合适的版本。实际上，如果许多屏幕阅读器未将盲文显示器配置为阅读屏幕阅读器日志而不是查看当前应用程序，他们就会剥夺盲文显示器用户的某些信息。
我正在创建一个支持盲文的音频游戏。这本身就是不寻常的——大多数音频游戏就是这样：音频。
我的第一个问题是如何让屏幕阅读器朗读消息并同时将它们传递给盲文显示器。对此的解决方案是 Tolk 屏幕阅读器抽象库
它像宣传的那样工作，但有一个问题无法解决：盲文消息发送得太快了。由于在许多屏幕阅读器（如果不是全部）中实现了盲文消息，如果两条消息一个接一个地发送，它们几乎同时到达，使用户在第二条消息出现之前没有时间阅读第一条消息（如果他们注意到第一条消息）。
在 Tolk 中，有一个函数Tolk_IsSpeaking()，如果屏幕阅读器正在说话，则返回 true，如果不是，则返回 false，或者如果屏幕阅读器没有实现这样的功能。
这就是主要问题：大多数屏幕阅读器都有一个缓冲区，可以在其中传递要朗读的文本。如果有断言消息出现，则缓冲区会在新消息被附加之前被刷新。这意味着大多数屏幕阅读器不知道他们是否在说话（这包括 NVDA 和 JAWS，这是我的主要目标受众），因此对于那些IsTalking总是评估为假的。
因此，检查屏幕阅读器是否正在说话，等待它停止，然后发送下一条消息是行不通的。
我想到的另一个解决方案是用户可以根据需要调整两条消息之间的延迟。屏幕阅读器会正常说话，而盲文消息会延迟。在主线程中实现它是一个坏主意，因为它会阻塞线程。但是我还没有弄清楚如何使用另一个线程来完成这项任务。
主线程必须启动并发送盲文消息，然后休眠一段时间。
主线程必须检查另一个线程是否终止（没有阻塞！），然后发送下一条消息。
如果有人知道如何实施上述解决方案或有不同的解决方案，我真的很感激。