Is your feature request related to a problem? Please describe.

NVDA Remote currently relies on a lot of monkeypatching to intercept braille, speech, gestures, tones and waves from the controlled system. #14503 intends to fix most of this, except for speech.

Speech is a difficult thing. Historically. NVDA Remote patched methods on the synth directly, e.g. speak, cancel. With speech refactor becoming available, this was changed to patch methods on the speech manager. This had several advantages, including:

1. Indexing and callback commands could be handled by the controller. This means that beeping in the middle of a sentence would work correctly, as the beep callback is executed by the controller
2. It was no longer necessary to patch the synthesizer

However, there are some drawbacks and current shortcomings:

1. NVDA Remote must mess around with the speech state. speech.speech._speechState.beenCanceled is set to False before NVDA remote can speak
2. Cancellable speech does not work

Describe the solution you'd like

I think that for NVDA Remote, the current approach should be preferred over the older approach where the controller relies on controlled system indexing. In other words, shortcoming 2 does not outweigh advantage 1. To solve shortcoming 1, it might be necessary to use speech.speak, speech.cancelSPeech and speech.pauseSPeech directly. On the other hand, for #3564, it makes more sense to work with a virtual synth driver, since the controlled system (or server) doesn't require local speech output. In that case, it's fine if the controlled system does the indexing and cancellable speech should work as well.

That said, we should solve shortcoming 1, e.g. NVDA Remote should be able to queue speech without fiddling with the internal speech state. Now I'm not very comfortable with this new approach yet. Therefore I hope @feerrenrut can share his ideas about this.

To avoid monkey patching, we need several extension points to cover both approaches:

• synthDriverHandler.synthChanged: To perform actions when a new synth is selected
• An extension point for speak. This can also be used for the speechViewer
• An extension point vor cancel
• An extension point for pause.

Additional requirements:

• Consider moving the filtering of redundant LangChangeCommand objects and handling of character commands, character and speechdict processing from speech.speech.speak to speech.manager.SPeechManager._processSpeechSequence. Note that it would make sense if a controller can use own preferences for language switching, symbol level, etc.

I'd love thoughts from @feerrenrut, @ctoth and @tspivey as well as other interested people.