Lukas Loehrer wrote:
> Willie Walker writes ("Re: eSpeak support in Orca -- what is the best way?"):
>
>> We recently looked at making a gnome-speech driver for eSpeak, but the
>> main problem is that the eSpeak libraries have no facilities for sending
>> samples to the audio device. Instead, it relies upon the application to
>> manage the audio.
>>
>
> I guess this is exactly why something like speech-dispatcher is a very
> good idea in the long run because it spares implementers of tts
> engines from dealing with the quirks of audio output architectures.
> Having written code for speech output with Alsa myself, I know this is
> not easy to get right, partly because low latency and instance
> interruptibility of playback is important in the tts scenario. Having
> this problem solved once and for all in a layer like speech-dispatcher
> will give people more time to focus on actual tts code.
>
Not sure I agree - the model where the TTS engine delivers its sample to
a "third party" for dispatch to the audio subsystem can increase
latency, rather than reduce it. I do agree that there are other
problems which such an architecture can avoid (for instance audio device
contention).
A key requirement is the ability to quickly stop an utterance. This can
be difficult with multiple processes in the mix. A corrollary to this
is the need for good progress/speech marker support, since in many
scenarios one needs to know how much was actually spoken before the
interruption took place.
Bill
> Best rgards, Lukas
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
