GNOME Bugzilla – Bug 572298
Speech-dispatcher is noticeably slow when continuous-reading links.
Last modified: 2010-10-10 05:40:32 UTC
This morning I experimented with gnome-speech's various services and the Orca SD backend. I found the latter to be the most stable with the behaviors I'd expect to find in a screen reader. It's also what I've been using regularly. But switching to gnome-speech revealed something it does well that the SD backend doesn't. When using continuous read on websites, the Orca SD backend pauses noticeably when reading links. Sometimes the pause is just a quarter second, but it is very notable on my EEE, where it might be a second or two. This is particularly difficult with consecutive links, and it's almost not worth continuous reading at that point. I'd been experiencing this for a while, thinking it was poor hardware, but since the behavior vannishes with the Espeak/SD Gnome-speech backends, that seems fairly conclusive to me.
Unfortunately, this sounds like it might be a problem with speech dispatcher, whose support is still in the experimental phase in Orca. I'm guessing it is a problem with speech dispatcher's callback mechanism.
reopening, since gnome-speech is to be depricated.
Unfortunately I confirm this problem with my computers. If I possible help any informations or testing fixes, I welcome help. I using Speech-dispatcher and Espeak speech sinthesizer, I use builtin Speech-dispatcher Espeak module, not espeak_generic module. My hardwares is a relative strong computers, but if a webpage containing continuous links, between the links have a relative big pause. My all computers have dualcore processor and 2 GB memory. I see this problem both Orca 2.30.1 and Orca git master version. Normal use Speech-dispatcher in my Lucid system is very good responsive, very fast to navigation with menues, controls, etc. Attila
I'm subscribed to the OpenTTS list and while the python bindings are being renamed to the new name, I expressed interest in regrofitting the speechfactory python module to opentts; more specifically, create a new openttsfactory.py to be cloned from the speech-dispatcher one. Perhaps I can follow up on this bug while setting the new opentts module. I'm new to python so dunno how theis other problem can be debugged bug can integrate whatever questions or issues back to opentts developers with greater smarts than me.
A bug with a resolution isn't really open; verified means that QA has verified that the fix (which we don't have) indeed works. As I change the status to not be verified, I cannot choose 'NEW' or anything else that would make sense as the status other than 'UNCONFIRMED'. Silly bugzilla.... So I'm setting it to 'UNCONFIRMED', after which maybe bugzilla will change its mind about what status I can choose. Apologies for any subsequent spam.
As I re-read this, I think it clearer if I go and create a new bug / RFE. I have already built the code for a new OpenTTS module which pretty much contains the same logic the present speechdispatcherfactory.py module has, except calls to speechd are replaced with opentts.
Closing again, since the problem has indeed been identified and fixed with opentts, as according to Trev: http://mail.gnome.org/archives/orca-list/2010-May/msg00490.html Trying to work around it on our end for sd might not be worth the time since opentts is becoming the new sd. Thanks Steve for taking the time to add in opentts support in Orca. Thanks.
Jon, you don't no what happened the Trew wroted bug fix with committed the OpenTTS speech backend, but not committed with Speech-dispatcher? For example the new released 0.7 version doesn't contaiining the fix. Attila