Open LiKe85 opened 11 years ago
@LiKe85, in the Ubuntu 12.04 test you ran above, was it a 32bit or 64bit install of Ubuntu?
In my initial attempt to reproduce on 12.04 32-bit with espeak 1.46.02, the first utterance stops properly, but the second utterance stops immediately after the first word without reaching the stop() in the callback.
On 32-bit 12.04 with espeak 1.46.02, I tracked the problem to a change in espeak behavior. In past versions that I tested,, an _espeak.Cancel() call would not cause the final _espeak.EVENT_MSG_TERMINATED to fire so I had added code to trigger it manually after a Cancel(). In 1.46.02, I can see the event is fired by espeak on Cancel(). Removing the manual trigger resolves the problem I mentioned one comment up.
I'll need to go back and look at older versions of espeak to see if I can support both behaviors. Or draw a line in the sand at espeak 1.46.02.
More pressing is why is the behavior I see different from the reported bug. I'll try 64 bit desktop next.
I used a 64bit install of Ubuntu with espeak 1.46.02.
The following test script was executed under Windows 7 and Ubuntu 12.04 and documents some strange behaviour of the
onStop()
function. The code was taken from the documentation example "Interrupting an utterance" and a second sentence was added to be read out.The test script:
Output under Windows 7:
Output under Ubuntu:
You can see that stopping the utterance in the example code works for the first execution of
runAndWait()
(more or less, since it should be stopped after the fourth word which it doesn't under Windows, but this might be some asynchronous timing issue), but not for the second.The second utterance with the exact same engine does not stop as requested but continues to read out all the text. This happens for both operating systems.
Another thing is, that under Ubuntu the given script crashes randomly after
stop()
was called. Sometimes even before the second utterance is started, sometimes during the second one. However, sometimes it is executed correctly and does not crash. Since this only happens under Linux this seems to be an issue with the espeak.py driver (my espeak version is 1.46.02).