Skip to content

Conversation

@DDRKirbyISQ
Copy link

This pull request includes the work done by mooreg-si in #8 in adding functionality to the WindowsTTS implementation to allow for changing the voice as well as adding some other functionality.

A tweak has been made to that implementation to use CP_UTF8 instead of CP_ACP when copying the string data on the native C++ side, to allow for unicode strings to be parsed correctly instead of being converted into ANSI. The x86 and x64 DLLs have been updated with this (one line) change. The resulting DLLs that I've included are also much smaller in size -- I'm assuming this is because mooreg-si's DLLs were compiled using a Debug configuration instead of Release.

In addition, I've added support to change the voice passed to the say command for the MacOS TTS implementation. I've added some comments as to how you can retrieve the available list of voices using say -v '?'.

The set of voices is of course completely different from the set used by the WindowsTTS implementation, so you'll have to figure out how you'd like to manage and map those on your side.

I'm unfortunately not easily able to test these changes locally as the project I have makes some additional internal changes to UAP, so feel free to let me know if I made any careless mistakes here.

- Update WindowsTTS.dll (x64 and x86)
- Fixes garbled (ANSI) text when using unicode strings
- Uses "-v" parameter to "say" command
- Use LPWSTR for pText in FormatMessage
@DDRKirbyISQ
Copy link
Author

I've identified a race condition in the WindowsTTS native code where the Initialize() call doesn't actually wait for the created thread to initialize its resources (i.e. pVoice). It's thus possible to call Initialize() from the C# side and then immediately try to call SetVoice() or anything else that uses pVoice and it will still likely be NULL, resulting in a crash.

It's been years since I've really touched any C++ code but I believe I've managed to solve the issue using a condition_variable along with the existing mutex so that Initialize() now blocks and waits for the thread to initialize pVoice.

Bad things will still happen (probably now a hang rather than a crash) if the initialization fails for some reason, but that's outside the scope of what I'm hoping to contribute at this moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant