English speech synthesis, flite linking (AIS-2218)

[MiLeG]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Described the feature in detail and justified the reason for the request.
• Provided specific use cases and examples.

Feature description

Hello,

Since the English speech synthesis is still to-be-released, I was forced to use flite or some adjustment of flite as an IDF component.

However, during linking it appears that flite is already precompiled inside the /lib/esp32s3/flite_g2p.a module.

I was wondering if the English speech synthesis feature is in the works, and is there a rough estimate for its release date?

Also, is the source code for the flite_g2p.a module available for access?
It would greatly help with integrating flite into my project, since the phonetic encoding that flite uses is wildly different from the G2P format which multinet uses as it's speech phrase structure.

Use cases

This way, I hoped to achieve a simple conversation agent using ESP-SR's multinet model and flite for English speech synthesis.

Alternatives

A workaround that seems to work fine is refactoring the doubly-defined symbols (mainly functions) in my flite component. This way they don't collide with the precompiled flite_g2p.a module.
The other alternative is to simply wait for English speech synthesis to be released in some way (pre-release or otherwise).

Additional context

No response

[sun-xiangyu]

Yes, the ESPSR includes some code from Flite—not for English TTS, but solely to convert English text into English phonemes, i.e., the G2P module.
As you’ve observed, MultiNet uses phonemes as input, which is rather inconvenient, so we opted for Flite’s G2P module.
We currently have no plans to develop or support English TTS.
If this module causes any issues for you, we can look into spinning it off as a separate component.

[MiLeG]

Yes, separating this into a component would be great.

If anything, it would enable me to use ESP-SR with flite speech synthesis without having to do some hacky refactoring to achieve this.

Some options that I would be happy with are as follows:

1. Having an official flite ESP-IDF component. This way there will be only one definition of flite methods, so no clashing definitions here.
2. Refactoring (renaming) the flite methods included in ESP-SR's flite_g2p module. Just so that those method definitions don't clash with an externally loaded flite component.

Sorry to hear that English TTS isn't in the works, but using flite seems like a straightforward way to achieve this.