GNOME Bugzilla – Bug 154250
Speech will be stopped when gnopernicus runs for a period of time.
Last modified: 2004-12-22 21:47:04 UTC
Steps to reproduce: 1. Launch gnopernicus and evolution. 2. Run some evolution operations with keyboard, such as changing the settings, composing new messages etc.. Do not wait for gnopernicus speech after every steps you fulfill. Bug observation: After a period of time, gnopernicus will speak nothing, but brlmonitor is still running correctly.
dup of 153416?
I believe this is a duplicate of bug #153416. John, can you check this? Can you provide a core file after speech dies?
John, is any message displayed by gnopernicus in its terminal?
increasing to AP0 since this effectively renders the desktop useless for the speech user.
*** Bug 154855 has been marked as a duplicate of this bug. ***
Created attachment 32508 [details] [review] proposed patch
reducing severity to AP1 because test reports that the bug is less troublesome than before, and that pressing Ctrl (i.e. shutup) seems to jolt the system back in to working properly.
The patch seems to solve the problem for Linux systems.
Wasn't the problem reported mostly on Solaris systems?
Yes, but yesterday, after I install the new system, build 20, I observe the same problem on Linux systems. Also Ctrl left seems to make speech start again. It is not easy to reproduce this bug, because it is not present after a fix number of steps and not in the same point, but with this patch applied I was not able to reproduce it.
The patch provided by Remus at comment #6 solves the speech problem on Solaris systems. I tested this patch with both 'kevin' and 'kevin 16' voices and speech does not stop working anymore.
Patch applied to CVS head and gnome-2-8 branch.
In some condition is possible to have following scenario: send text 1 to freetts (*) receive start marker for text 1 send shutup for text 1 (!) send text 2 to freetts (**) receive end marker for text 1 /* ------- root of the bug-------- */ (!!) receive start marker for text 2 receive end marker for text 2 /* from here gnopernicus stops to speak */ The explanation is: When a string is sent to freetts (gnome-speech in general) some information are added to a queue (implemented by srs_gs_outs list). The information is removed when a shutup command is sent to speech or when an end marker for the information is received. In our case, the information is put in queue for send command (*) and removed for shutup command (!). New information are put for second send command (**). When end marker is received (!!) the information for text 2 is removed (_wrong_) and now the queue is now empty, even freetts is speaking. When markers for text 2 are received , they are rejected because the queue is empty. So, the solution is to remove information from queue for an end of speech marker ONLY if the marker is for text for which information is, otherwise it is for previous information and has no interest.