izabela-desktop
izabela-desktop copied to clipboard
Wurielle
0.10.3 voices still changing and delayed inputs.
My friend is experiencing issues with the US English Female voice. It suddenly started using a newer deeper voice that they do not like compared to the old one they used. It uses the old voice still on a few words but sentences all use the newer voice. We saw that 0.10.3 fixed this but the issue is still occurring despite updating. Inputs seem to be also be delayed or never send.
I released v0.10.4 which should fix more inconsistencies with voices.
I don't have any control over the voices returned by Responsive Voice. They recently updated their API and I have no choice but to follow their updates.
Are you experiencing a delay between keypresses or between the time you send a message and the time you hear the message?
v0.10.4 seems to have fixed the inconsistencies but exclusively uses the newer voice which they don't like. I understand you may not be able to fix that on your end unfortunately, but I attached some audio clips for comparison. As far as delayed inputs go it is a delay between the time a message is sent and heard. AudioExamples.zip
There's an update regarding the "new" voice vs "old" voice issue, you can read about it here.
I can't find a cause for the message delay. Press-to-Talk and the Say API both add some delay to messages which is a known issue that will be fixed whenever it can be. If you're using either or both you're gonna experience some delay which I cannot fix right now.
If it's not the case maybe that could be a latency issue between you and the server (in case you're using the Responsive Voice API).
I'll keep an eye on the issue either way.
Thank you for the response and update, it seems like latency could be the issue with where my friend lives. The voice engine fix gives a voice much closer to the one used before, just slower and more robotic sounding. It might also be worth noting that the pitch slider has no effect on the new optional voice engines.
I'm working on my own tts api hosted in EU and US which hopefully will solve these 2 issues but I'm not ready to implement it yet (but I hope I can soon).
As I stated above I don't have any control over the responsive voice api, choose the say api if you encounter issues with the responsive voice api.
The Say api uses SAPI voices delivered by windows so there shouldn't be any noticeable delay with Say and you can download more SAPI voices if you feel like it which makes it a solid alternative until I can implement my own tts api.