[orca-list] orca, speech dispatcher, and certain synths

[Jacob Schmude <j schmude gmail com>]

Hi List
I'm noticing different behaviors with Orca and speech dispatcher  
regarding punctuation marks and spaces, depending on which output  
module I'm using. Espeak, for example, speaks everything just fine  
including all punctuations. Some punctuations produce an echo, but  
that's an espeak problem not an orca issue.
When using the ibmtts module, on the other hand, spaces and the less  
than (<) and greater than (>) punctuation marks are not spoken when  
moving character by character. Interestingly enough these two  
punctuation marks will speak when pressing the current character key  
twice, i.e. invoking the phonetic spelling. Spaces still do not speak.  
If I change the punctuation setting to most in Orca, these two symbols  
read as "l-angle" and "r-angle" when moving character by character,  
but normally when phonetic spelling is used. Feeding these strings to  
speech dispatcher directly, however, does cause the < and > marks to  
speak as one would expect. This issue seems to occur both with the  
ibmtts module and with any modules based on a generic say command.  
Espeak is unaffected by any of this.
These issues do not crop up at all when using the speech-dispatcher  
gnome-speech driver rather than using speech-dispatcher directly. The  
trouble with this approach, though, is that there seems to be no  
callback support in this driver and therefore the say all function  
will not work, as well as being slightly less responsive.
I wish to use speech dispatcher rather than any of the gnome-speech  
drivers due to speech-dispatcher having native support for different  
audio subsystems, i.e. it does not rely on the synthesizer itself to  
perform the audio output, but handles that directly. I wish to use  
engines other than espeak, but it seems neither ibmtts nor cepstral  
like to be used with audio wrappers such as aoss or padsp. They work  
for a bit, but become very unstable and I've had a lot of lock-ups due  
to this which required me to send a sigkill to their processes before  
the desktop would unfreeze--yes, the GNOME desktop itself completely  
locked up on these occasions. Running these drivers through a wrapper  
is necessary, otherwise they attempt to use direct OSS output which  
overrides any software mixing, be it alsa's Dmix or Pulseaudio. Speech- 
dispatcher doesn't usually lock and even when it does it doesn't take  
the desktop down with it, and there's no need for audio wrappers, so  
it's a much better fit for my setup.
Anyone know what's going on here, why it affects some modules but not  
all of them?
Thanks




   The major difference between a thing that might go wrong and a  
thing that cannot possibly go wrong is that when a thing that cannot  
possibly go wrong goes wrong it usually turns out to be impossible to  
get at or repair.
        --Douglas Adams