Very long delay when speaking stopped (windows / sapi5)

[jimbr32]

I'm using Cepstral David and Callie (version 5.1) with a windows sapi5 application and seeing a very long delay / hang when trying to stop speaking.

The problem can be duplicated using the Microsoft Sapi5 SDK demo application (Sapi5 TTSAPP). Load around 1000 words into the text entry box, press the speak button, wait a second or two, then press the Stop button. On my system, the app hangs for around 15 seconds before the Stop seems to complete.

Is this a known problem or possibly a problem with my install?

[GoldenMouse]

I have a similar problem. I am under Windows XP SP3, x86, and swift application takes FOREVER to start speaking and won't read anymore after a period. I'm trying the unlicensed Amy voice, and after reading, it also freezes for a long while, so if I try to read another sentence, it can take up to 1 minute to start reading that new sentence. I thought it could be something in my system, but I can't see any issues on it.

Anything I could do to fix this irritating problem?

[EDIT] I've just checked and seems like COMODO firewall was obstructing it. After disabling it, I can even spam the TTS system and make it read almost instantly... however I wouldn't like to have my firewall disabled. Which rules should I create to avoid it blocking the system? (However, it is a bit strange, why would the firewall have anything to do with the voices?)

[EDIT 2] Nevermind, after using it again a few times, it got stuck again, I guess it was just a coincidence.

[jimbr32]

I'm still having this freeze problem when I try to stop speaking. Any ideas? Cepstral David and Callie, version 5.1, with a Sapi5 application.

[AdamW]

I think this is old issue (before my time at Cepstral). I think it has something to do with people trying to synthesize ENTIRE books, so the synthesis engine starts chugging away with the synthesis and doesn't complete the stop request until all the different engines on all the different tracks come to a stop.

I would be interested to know if the issue occurs with short files as well for you.

-- AdamW
Cepstral Support

[jimbr32]

Hi Adam,

Thanks for the reply. The problem does seem to be related to how much text is speaking, but the problems is present with short documents. For example, if I load the text of the Gettysburg Address (< 300 words) into the Visual Basic Sapi5 demo application (TTSAppVB) and speak it, pressing the Stop button in the demo app takes around 4 seconds to complete. If I paste the Gettysburg Address in twice (< 600 words), the stop delay is right around 6 seconds. If I load only the first sentence of the speech, stop time is much faster, under a second.

The voice I'm using is Callie, version 5.1.0

Are these delays normal?

[BJinPass]

I am having a similar, yet worse experience with the Marta and Miguel engines. I am finding that at a certain point (approximately 1300 characters into the script), my call to cancel speech fails and hangs. From this point on, speech doens't work until I restart my application. I have have found no workaround short of shortening my script, which is unacceptable for what I am trying to do.

Have you found any way around the problem of stopping a long string of text? I am also experinencing stop delays related to the length of what is being spoken.

[BJinPass]

I have come up with a workaround for the problem I am experiencing and what the others are experiencing. For me, a large input file would result in the engine (Marta in my case) never returning from a stop command. Others experienced long delays when stopping.

My solution was to parse my script into separate strings. Because I control my scripts, I rewrote the code to send the engine only the next line of text, defind as up to the next 0x0D 0x0A. For me this works extremely well as a workaround. No noticable delays are heard in sending long scripts as spearate speech commands. It has decreased the stop time to almost nothing, which is another benefit.

This workaround seems to solve my problem but if you don't have the ability to add CR-LF characters to your text, then you may have to parse it differently. All in all, as a workaround, there are really no issues with it.