SAPI and Onecore Text-to-speech unified adapter

[NPavie]

SAPI and Onecore TTS support

Changes required for enabling Microsoft SAPI and OneCore text to speech synthesis within the DAISY pipeline 2.

Given the similarity between the 2 engines (OneCore and SAPI Voices uses the same structure but stored under different registry keys), connection to those are enabled through the tts-adapter-sapinative adapter, that manages the 2 native libraries using the different APIs needed to interact with them :

• the sapinative library has been fixed to correctly handle ssml, including marks, with the SAPI TTS runtime
  • it has been moved from the sapi-nar project to the tts-adapter-sapinative one, as only this adapter uses it
• A new onecorenative library is hereby provided to synthesize speech from ssml markups with the OneCore TTS runtime
  • As for SAPI, the engine also handles marks
  • This library uses C++/WinRT bindings to interact with the OneCore runtime

Both libraries are provided pre-built as dlls within the adapter for windows x86 and x64 systems, and the correct dlls are automatically loaded by the service based on the JVM architecture.

If needed, they can be rebuild with visual studio 2022 community, using the sapi-onecore-native.sln solution.

Note for users of the adapters that have third party SAPI voices : voices that are installed under the 32bit (x86) registry cannot be used through this adapter if the jvm running is not also 32 bit. This is due to x86 and x64 voices registry of SAPI being not unified, meaning that an 64bit application that uses SAPI will have only access to the voices that are installed in the 64bit registry (and similarily, a 32bit application will only have access to the 32 bits voices registry). Some hacks can be found on the web to "copy" a voice from x86 to x64 registry, but this hack has been tested only for Microsoft Voices and might not work for a third party voice. To use 32bit voices, you will need to run the pipeline with a 32bit java runtime.

[bertfrees]

@NPavie Thanks!

• the sapinative library has been fixed to correctly handle ssml, including marks, with the SAPI TTS runtime

  • it has been moved from the sapi-nar project to the tts-adapter-sapinative one, as only this adapter uses it

If I'm not mistaken this was already done in commits https://github.com/daisy/pipeline-modules/commit/0eb76a386cf5e69df8cb20d5d7d6648ce15d6fe2 and https://github.com/daisy/pipeline-modules/commit/d2cad09325d21131805775113a196dfb297f1c2b. So it looks like at least the first three commits in this PR are not needed. Could you please check and update the PR accordingly? (Update: this is done)

[bertfrees]

The "fixup" commits f7c50407fe04fbc65b3fce17e956c9c1458e959e, 26b708aaa578b3336af16c77b801d35ff881177c and b5c49e2d6b39b61ec827adc7ded2a0a372633eaf should be combined with the right commits that they fix. (Update: this is done)

[bertfrees]

@NPavie I'm doing some cleanup right now. I have reduced the PR to three commits. I still have some work to make each commit compile and to clean up the source code a bit. I also plan to delete SAPIService and rename OnecoreService to SAPIService.

[bertfrees]

@NPavie Everything is in a single commit now. There is now a single TTSService called SAPIService (in the org.daisy.pipeline.tts.sapi.impl package) for both legacy SAPI and OneCore voices.

Ideally I'd like to move all Java classes to the org.daisy.pipeline.tts.sapi.impl package because we don't need public packages. How much work is that? If it is too cumbersome we can leave it.

I have some more questions, I will add comments in the code.

[NPavie]

A quick update with the latest commit update :

• I change the way the libraries initialization and disposable are handle by the service, to allow for multiple class to interact with it, so that tests class can now run concurrently :
  • 2 set of "load" and "release" methods are now provided by the service, with a "request counter" for each library to only dispose the library when every objects requesting it (with the load method) have called the release method at the end
  • Tests have been changed to use those load and release methods instead of the previous "loadDLL", "initialize" and "dispose" calls. Tests run concurrently and report no failures on my windows machine.
• I re enable the ending mark test and with the ssml fix, the ending marks are correctly reported.

[bertfrees]

Perfect, thanks! You can just add fixup commits to the branch, that makes it easier for me to see what changed since my last review. I will then squash afterwards.

[bertfrees]

Merged in https://github.com/daisy/pipeline-modules/commit/9f0cfc5ceb4475d60520d3c1d6b6148fb80ff920.