Revert "Fix SAPI4 WASAPI implementation (#17999)" (#18096)
### Reverts PR
Reverts #17999
### Issues reopened
Reopens #17964
### Reason for revert
In the "Known issues with pull request" section of #17999:
> This is not the same behavior as the built-in WinMM implementation,
which uses a buffer of a fixed size, and will reject new data when the
buffer is full. So it's possible that this behavior doesn't work well
with some certain voices.
As a user reported, this makes certain SAPI4 voices respond slower when
the text to be spoken is longer.
Those SAPI4 voices won't start playing the audio until the audio buffer
is full or the whole utterance has been synthesized. As #17999 made the
buffer size "infinite", the audio buffer will never be full, so the
longer the text, the longer it takes to synthesize the utterance, and
user have to wait for the entire utterance to be synthesized.
The built-in implementation uses a buffer of a fixed size, so the buffer
will be filled up quickly, and the audio will start playing while the
rest of the utterance is being synthesized.
### Can this PR be reimplemented? If so, what is required for the next
attempt
We should look for another way to fix the problem, and make the WASAPI
implementation as similar to the original implementation as we can.
Unfortunately I haven't been able to reproduce #17964 yet. So I want to
revert #17999 first to prevent breaking more voices.
