Link to issue number:

None

Summary of the issue:

In #17718, I changed the SAPI4 synthesizer code, so that SAPI4 can now use WASAPI WavePlayer for audio output. This was done by creating a custom audio output destination class, and let the SAPI4 engines use the custom destination instead of the built-in MMAudioDest to output audio.

The engines interact with the audio destination object directly, and each engine may have its own way to use the audio destination object. So while the current implementation works with some of the SAPI4 engines, it may not work well with some other engines. As different engines have different behaviors, it may be impossible to replicate the same issue with another voice.

It would be better if I can get access to the exact same voice and study its behavior. But many of those voices are commercial products, which require purchasing and activating, so I cannot easily get the voices.

The second option is to get the log file from the user and study the logs. While I am using logs to debug on my side, the logs may be too chatty for regular users, because every audio chunk would be logged, so I decided to leave the logging part out. But now I find it difficult to diagnose SAPI4-related problems without logs when I can't get access to the voice.

Description of user facing changes

When the debug log category synthDriver in the advanced settings page is enabled, additional verbose SAPI4 logs will be enabled, which includes most of the interactions between the SAPI4 engine and the custom audio destination object, including every audio data write.

This can log many lines when using SAPI4 voices, so it's recommended to keep the log disabled when not necessary.

Description of development approach

Added logging in the SAPI4 module, which can be enabled or disabled by the synthDriver debug log category.

Testing strategy:

Tested manually.

Known issues with pull request:

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

@coderabbitai summary