Progress

[thomaslloyd]

The client and server now have methods to allow individual transaction
level debugging. Now when required we can track the point of failure
more granularly. I am hoping that this will throw up a clue as to the
cause of the system freezes. Through this system we also have timeouts
on each task issued through the server. The idea behind this is to
make sure the system doesn't become totally unresponsive as it
currently does. The client will always die releasing speechds control
of the GUI. From there depending on where the issue likes I may need
to implement a thread on the server which checks its own health or
that of SAPI and respawn itself if is has become unresponsive. As it
stands the client only monitors timeouts but the server may also
benefit from a similar service.

Updating Wine to the latest binary release has solved a few issues. On
my system occasionally PulseAudio keels over. I would be interested if
people could again test on systems using pure ALSA (vinux thats you).
This type of crash only happens under very heavy load on the sound
server. The system does not become unresponsive but the SAPI server
will not speak until pulseaudio is run again. This is more reliable on
the testing PA release i am using from upstream.

Please update wine, if your using PA then on request i can give some
update information and test away again for me. Again the system seems
to freeze while it is reading. I am not sure but think this is a
limitation of using the generic module for SD so implementing an open
sapi module is becoming a higher priority.

Tom
I suspect that speech dispatcher is in part to blame and will try to
get the latest GIT release built and installed soon to do some futher
testing. Anyone have some experience with that can you drop me an e-
mail.

[thomaslloyd]

Further investigation has identified the pulseaudio issue only
happening under extreeem load where the sound system is under the
highest level of stress that can be applied to it. Pulse exits with a
Soft CPU timeout and says that the maximum CPU time delay has been
reached. So this seems to be a feature not a bug in pulseaudio but
there maybe a need to extend this delay by a small amount to cope with
this backlog. The developers of pulseaudio probably do not have a
usecase for this feature but have implemented it all the same and not
come across a scenario that uses it.

Finished implementing the timeouts on the client so it will never in
theory take control and lock up speech dispatcher. The server status
system is not yet completed but the methods are there I will redesign
the procedure communication methods to pass information around in a
global array. This will save having to make unnecessary calls.

The two candidates for the system freezes are now orca and speech-
dispatcher or a combination of the two maybe ;). How i love the
interactions in this project soo much. Let the testing continue. Orca
is also throwing up some strange error messages so it could be a
problem there. Sill need to get a comprehensive logging system in
place, now i have some data to log.

Tom