[v1.7.2.17] Asynchronous TTS actions prevent commands from completing

[Pfeil]

This is the issue originally discovered in this topic, made into its own topic as it appears to differ from the one the OP describes.


Replication is possible by executing the following command rapidly, using a keyboard shortcut:

Code: [Select]

Write [Blue] 'Beginning test' to log
Say, '1'
Say, '2'  (and wait until it completes)
Say, '3'
Say, '4'  (and wait until it completes)
Say, '5'
Write [Blue] 'Ending test' to log

Doing so leads to very few commands actually finishing, as indicated by the lack of "Ending test" entries in the log, and "Stopped command, ''" entries when stopping all commands.

Testing in v1.7.2.17, pressing the keyboard shortcut 5 times in roughly 1 second will result in only one command finishing correctly, with only one "Ending test" entry in the log, and four "Stopped command, ''" entries upon stopping all commands.

This hasn't come up in almost ten years, so, I'm not going to classify this as an emergency just yet.

As there is probably little point to having TTS play over itself, especially in rapid succession, I don't think anyone minds if this is categorized as "noted".


EDIT: Fixed in v1.7.2.20

[Tkael]

In my case, this issue results in VA crashing on the second instance where the command is executed.
Button mashing is not required to achieve a crash - I simply allow the command to complete and then execute it a second time.

Steam version. 'Single TTS Instance is checked`, `Enable plugin support` is unchecked, the speech engine is the Windows default (Windows 10 x64), and the audio output type is `Integrated components`. Selected voice is Ivona Amy.

Suspected but unconfirmed as a possible source for reports of VA crashing with the EDDI plugin installed, since EDDI `say` actions are synchronous while VA `say` actions may be either synchronous or asynchronous.

[Gary]

VA TTS is asynchronous unless it is routed.  It is then synchronous, but only for an extremely brief period (milliseconds).  VA does not use the synchronous aspect of TTS to do the, 'waiting'.  Just FYI

[Gary]

Taking another look at this today.  The number of active synths at one time may be a culprit (theory).

[Gary]

Hoping to be moving in the right direction with this.  I put a build out in the, 'unofficial' bin for both standalone:
http://www.voiceattack.com/unofficial

and Steam: http://www.voiceattack.com/unofficialsteam


What I've done is limit the number of active synths to 3, as allowing more somehow throws off the synth components.  I don't know if that number would interfere with synths launched in plugins - if that is the case, I would recommend running VA with single tts.

@Tkael - something to note is to limit the number of synths that are used as well as making sure that when you are done with a synth to properly dispose/gc.  I spent a bit of time scratching my head messing around with different layouts only to find out I neglected to dispose my synth o_O.

[Tkael]

I've already looked into that a bit. We spin off a dedicated thread for the synth and enclose the synth in a `using` statement which automatically disposes the synth once the speak action is completed.

The code is located here if you are interested in reviewing it.

`Single TTS Instance` has remained checked throughout all of the testing I've been doing on this issue.

[Tkael]

Testing the latest "unofficial" build on Steam, VA appears to be rock solid with plugins disabled.
However, all variants where EDDI's say action is invoked in between VA say actions still result in crashes. I'll continue on the other thread.

[Pfeil]

v1.7.2.19("regular") runs fine on my machine(I do have plugins enabled, but EDDI is not one of them).

Spammed the command, 60 beginnings, 60 endings. Keyboard shortcuts also kept working.


Would the time and overhead be worth it to have a "Text-to-speech cancelled, cannot run more than three instances simultaneously"-style message in the log?