Your comments
Hello Pavel!
This is typically an indication of failure of the TTS request.
Failure could be the result of bad input - or could be something else
I'd need your account ID (or login email) to check our logs & advise further.
Please share either here or by sending a note to our support.
Standing by,
Gil
The SitePal Team
Pavel,
Thank you for your patience & feedback as we investigated & addressed this issue.
The nature of the problem, which involved a particular sequence of events and timing, was challenging to track down. Thanks to your assistance we were able to.
Best regards,
Gil
Hi Pavel - this issue should now be fixed. Please clear your browser cache and let me know if you still see the problem.
Best,
Gil
Hi Pavel -
We are working on it. I expect that we will have an update soon.
Thanks for your patience - will advise asap.
Thank you for the detailed info.
We'll look into it and advise asap
Hello Pavel -
We've recreated your example on our test server here - https://www.workboy.com/qa/vue_client_example/index.html
(you need to accept the provisional cert)
We can see, both in your example and in ours, that the third audio sometimes does not play and appears to be skipped. But that is not actually the case.
What happens is that the delayed stopSpeech call is called after sayText is called, but before the audio starts.
So the audio never starts playing and appears to be skipped.
This behavior is per spec. not a bug, but a feature :-)
In your original note you say that - "After few calls, the sayText() does not start speaking."
it sounds like you may describing a different problem than the one demonstrated by your example.
If that's the case - pls provide a clearer explanation and/or better example - and we will investigate asap.
Best,
Gil
Understood.
If the speech is not being stopped by the need to play another audio, then my comment does not apply. You are doing the right thing by calling stopSpeech. No need to modify.
We're looking into it and will let you know when fixed.
Best,
Gil
Hi Pavel, we are able to recreate the problem and are working on it. I don't yet have an ETA.
I'm wondering - what is your purpose in calling stop speech after 4 seconds? Is there a special reason you need to interrupt the previous speech precisely after that delay? Or is this just a way to recreate the issue & bring it to our attention? (worked!)
I ask, because if you simply need to interrupt one speech with another, there is no need to use stop speech for that.
Just turn ON "Interrupt Mode" setting, and any newly requested speech will be immediately launched.
You can do so using the 'setStatus' api call, and it may work better for you.
Regardless - we will address this issue.
Best,
Gil
Customer support service by UserEcho
I saw. Thanks
I checked the logs and responded to you with detailed info.
Please check.