Bring back the older WinMM-based SAPI4 implementation (#17801)
Based on discussion #17792.
Summary of the issue:
My current WASAPI implementation for SAPI4 does not work with every
existing SAPI4 voices yet.
Most SAPI4 voices rely on the SAPI4's built-in WinMM implementation. The
current WASAPI implementation behaves differently compared to the
built-in implementation, which breaks some SAPI4 voices. Studying and
replicating the behavior of the built-in implementation is also not
easy, as this implementation is not open-sourced.
Description of user facing changes
A setting item, "Use WASAPI for SAPI 4 audio output", is added in the
Advanced settings page.
It is enabled by default, which makes SAPI4 voices use my WASAPI
implementation.
When disabled, SAPI4 voices will use the old built-in WinMM
implementation to output audio.
No matter enabled or disabled, verbose debug logs for SAPI4 will be
generated when the debug logging category "synthDrivers" is enabled in
the Advanced settings. Users are encouraged to try both implementations
with verbose debug log enabled when filing related bug reports, so that
we can compare the difference in behavior between the two
implementations more easily.
Description of development approach
WinMM related code, introduced in #17599, is brought back.
A feature flag, `useWASAPIForSAPI4`, is added in `speech` section.
Class `SynthDriverMMAudio` is added in sapi4 module. It's a wrapper for
the built-in MMAudioDest, which can log the interactions with the TTS
engine, with the decorator `_logTrace`.
Testing strategy:
Tested manually.
Known issues with pull request:
None yet
