Re: [orca-list] Speech system shootout

[Michael Whapples <mwhapples aim com>]

Hello,
A good lot of information there, hopefully enough bor you to report bugs 
and improvements well enough for developers to attend to them. OK so 
where to report, I will mark this inline amongst your original message.
On 23/12/42 19:59, Nolan Darilek wrote:
> Hi, all.
>
> I've been  using the Orca Speech-dispatcher support for a while, and 
> recently decided to play with the other choices, wondering how 
> performance and such differed. I've had mixed experiences with each 
> and thought I'd share them. Since each behaves well or poorly in a 
> variety of ways, I'd like to file bugs but don't know where to file them.
>
> Gnome-speech with Speech-dispatcher: This seems a bit more responsive 
> than my initial SD solution, and I find that I can type ahead of 
> characters as they're speaking, which is refreshing. The first thing I 
> encounter not working, though, is say all. It seems to read one 
> element in Firefox--paragraph, header, whatever, then stop. This isn't 
> true in the Thunderbird message entry window or in Gedit. I also 
> couldn't get the voice to change at all--it remains a British male, 
> even when set female.
This sounds like gnome-speech problems, report to the gnome bugzilla 
(http://bugzilla.gnome.org). My personal feeling is the say all problem 
might lie in the SD driver for gnome-speech, but I wouldn't put money on 
it. Have you tried altering the say all by option in orca?
As for the male and female voices again the SD gnome-speech driver 
probably causes it (if other SD software can use both male and female 
voices for the same synth it rules out SD). However if other SD software 
can't make use of both male and female voices then it may be a problem 
in SD so report it as described at www.freebsoft.org (I don't know their 
preferred reporting of bugs, but there is mailing lists).
> Gnome-speech with Espeak driver: This has the best say all 
> performance, reading everything very quickly. It also stops the cursor 
> very close to where I stop reading. I have to cut my test short, 
> though, because it doesn't interrupt itself when I type, making my 
> first attempt at typing this paragraph painful.. I also seem to recall 
> it getting interrupted during a say all by an IM and just stopping, 
> which is rather frustrating.
> Again sounds like gnome speech, I don't notice interrupt problems, but 
> I don't have echo characters on so don't have very rapid interruptting 
> but haven't noticed a problem when quickly navigating by lines. Aside: 
> this is my preferred option, in GRML/debian it seems to use ALSA by 
> default and so just works with other sounds.

> Native speech-dispatcher: This behaves the closest to what I'd expect 
> a screen reader to do, though it has its quirks. Say all doesn't stop 
> as happens with Gnome-speech+SD, nor is it interrupted by new text as 
> is true with Gnome-speech+Espeak. Rather, new text gets inserted 
> neatly into the flow, albeit sometimes not as immediately as I'd like. 
> It's also very responsive for typingg. It has its quirks, though. I've 
> noticed a commonality in both SD drivers in that there is a noticable 
> pause for punctuation, even when none is spoken. For instance, run 
> spd-say with the following test strings:
>
> "This is a test."
> This is a ( test ) ."
>
> This part is obviously an SD issue, and I'm not immediately sure how 
> to resolve it, other than to check whether all the contents of a 
> string are beneath the punctuation threshold of the currently selected 
> mode and are non-alphanumeric, and if so remove them from the string. 
> I notice this behavior at other times, too, like before links are 
> spoken. There is often a pause of nearly a second before the word 
> "link" speaks. There are also other inconsistencies. " is "double 
> quote" when typed, but "quotes" when backspaced over. Some of the 
> character names are just plain strange. ' is "quote", " is "quotes," 
> but only when erased, see above. :) ( is "left bracket," [ is "left 
> square," { is "left brace." Even after nine months of use, I still 
> have to pause and ask myself which is which as this is inconsistent 
> with every other speech system on every other OS I've used, and that 
> isn't because each is inconsistent with the other. :) The SD driver 
> doesn't seem to stop as smoothly, either, and usually I have to find 
> my place when concluding a read. Despite these quirks, though, I'd say 
> that for an experimental driver, it is closest to what I'd expect 
> from  a screen reader.
The native driver is part of orca, so probably reports should be against 
orca, I don't know what the supported status of the driver actually is 
and what emphasis would be associated to SD driver issues. Say all by 
certainly falls into the category of the drivers issues.

As for the punctuation comments, the pausing seems to be an SD issue 
(particularly if spd-say shows it). The only exception would be if you 
only encounter it with one synth in SD, in which case it may be the SD 
driver for that synth or it may be to do with the synth itself. As for 
the naming of the punctuation, I don't know where this happens, there's 
so many places it could be named, orca might give it a name, 
gnome-speech (if used) might give it a name, SD (if used) might give it 
a name and the synth might give it a name. So if using the SD 
gnome-speech driver you have four places which might give it a name. 
Also I don't know what happens when something doesn't name it (either 
because it doesn't know it, isn't meant to name it because of punct 
level or another reason), if it just passes it on then something further 
along the chain may decide to speak it (so leading to a mixed 
punctuation naming system). I don't know whether that has helped, but it 
might explain why things don't match between typing and erasing (IE. SD 
has a fixed punctuation level, so SD gets more characters when doing one 
thing than another because orca might be naming more characters when 
doing certain things like moving character by character). The only other 
explaination I can think of (although I don't think it is the answer in 
this case) is to do with knowing context, eg. if I write 3.3 the dot 
there can be guessed to be a decimal point and we are likely to be 
correct with our guess, but put a . by itself what is that to be named, 
full stop, decimal point, dot?
> So why dump all this on the Orca list? First, because it is the 
> user-visible entry point into each of these systems. Next, because I 
> don't know where some of these issues should be solved and am hoping 
> that someone here has a clue. :) If both Gnome-speech drivers didn't 
> handle say all correctly, I'd conclude that Gnome-speech or Orca might 
> be at fault, but one of them handles it fine while the other doesn't. 
> Same deal for interruption of typing, both drivers in the same system 
> are inconsistent. I suppose it could be issues with the drivers 
> themselves. In that case, I'd be interested in reading others' 
> experiences with these systems, workarounds, etc. And,  again, I'm 
> happy to file bugs if we know to where they should be sent. :)
> I think this list is a good place for this information, it relates to 
> how you find orca is to use, even if the actual issue isn't always 
> orca. However if I have convinced you and if others also think the 
> same about what is causing the problems then please report the bugs to 
> the appropriate places as that is the best way for you to get it 
> noticed by developers.

>