Re: [orca-list] Built in Controls for Espeak Pretty Please with Sugar, cheeries, whatever it takes on top :)

[Thomas Ward <thomasward1978 gmail com>]

Hi,

On 8/29/14, B. Henry <burt1iband gmail com> wrote:
> Question, specifically why would a new bridge between apps and synths be
> better than speechdispatcher?

I just think the way speech-dispatcher handles synthesizers needs to
be redesigned from the ground up because it seems flawed. I know that
gnome-speech had problems, but often seemed to have better support for
various TTS voices than does speech-dispatcher. What I initially was
thinking was bring back something like gnome-speech, but updated so
that it would work with everything from console apps to various
different desktop environments. However, in hindsight I do think
simply upgrading speech-dispatcher might be the better solution.

> I am saying if one spent the same time fixing speechdispatcher that one
> would spend on starting from scratch would things
> advance further, and if not, what is so fundamentally wrong with speech
> dispatcher that makes it not very fixable?

I wouldn't go as far to say speech-dispatcher is unfixable, per se, I
just think the way it was designed was wrong. I need to look more at
the specifics of how speech-dispatcher works to address specifics
here, but from what I have noticed essentially speech-dispatcher tends
to pipe text through command-line parameters sent to the synthesizer's
console interface rather than directly accessing the libraries
directly

For example, to access the Cepstral voices I believe speech-dispatcher
sends text to swift which then speaks the information via the voice
installed. That's a pretty inefficient means of accessing the Cepstral
voices. .I think speech-dispatcher should link directly to the
Cepstral libries and send strings of text directly to the synthesizer
rather than going through swift. However, as the Cepstral TTS voices
are not free and open source this could present problems for package
maintainers who may not be able to compile the source and will have to
compile speech-dispatcher without Cepstral support. That's, of course,
a disadvantage of linking directly to the libraries rather than the
more scripted approach we currently have now.

In other words, the point I am making is the way speech-dispatcher
communicates with many of the TTS engines it supports is slow and
inefficient. It can be fixed, but it needs to be redesigned.  I am no
expert when it comes to speech-dispatcher since I have not looked at
how it works too closely, but from what I have noticed it does not
directly communicate with a number of TTS engines, and often does so
in a roundabout way which is a quick hack at best.