Re: Progress with AsteR installation

[Tim Cross <tcross@xxxxxxxxxxx>]

> Tim Cross <tcross@xxxxxxxxxxx> wrote:
>  
>> The openTTS code does have a CL package that provides a speech interface. At
>> least, it did when it was speech-dispatcher. The code is quite simple, but was
>> a little limited in that it wold only work correctly with one specific version
>> of CL. From memory, this was either CMUCL or SBCL. 
> 
> They're related, as you know.
>>

Yep, SBCL was originally a fork of CMUCL. The main problem with the SSIP
package is that it relies on networking support to communicate with the speech
server. Unfortunately, the ANSI CL standard didn't cover networking and many
other 'standard' areas that are usually part of standard libraries in more
recent languages - an artifact of when the ANSI standard was defined I guess.
As a consequence, the way CMUCL, SBCL, CLISP etc handle networking varies, so
you need to have separate code for each flavor of CL. Luckily, this is
reasonably easy to handle with the + and - compiler directives. The only
downside is it means more code and more code means more potential bugs!
 
>> I did provide patches to them on at least three occasions, but the last time I
>> looked (over 5 years ago at least), they had not been included. I'm not sure
>> if I still have the patches or not, but theyw ere pretty trivial and I can
>> easily  reproduce them. 
> 
> The new maintainers may be more cooperative. They're also fixing large numbers
> of bugs, such as memory leaks, in the C code.
>
Yes, I've noticed they have had quite a few fixes in both the C code with
respect to memory leaks and fixes to improve pulseaudio handling etc. In
principal, I think the openTTS approach does have some real potential, though
I'm not familiar enough with the specifics of the protocol to assess how good
it really is. Experience has taught me to be somewhat reserved when it comes
to protocols that are designed by committee - they often end up over
engineered. As an example, consider CORBA, SOAP and REST. The CORBA
specification ended up so complex that even now after over 15 years since the
spec was first developed, the OMG still has to admit there is still no fully
compliant version. SOAP started out aiming to be a 'simple object access
protocol', but over time has begun to show more complexity than was originally
aimed for and to some extent, as a consequence, REST has developed because
often, you just want something simple and light weight. 

In comparison, while the protocol used by emacspeak may lack a clear formal
specification, it has evolved to meet actual requirements rather than
theoretical ones. Sometimes, such an approach can result in inefficient or
less than optimal design, but provided you are prepared to refactor and refine
things as experience increases your knowledge and understanding, you will
usually end up with a better result in the end. 

In my efforts to get espeak working well, I've noticed a number of
inefficiencies and possible limitations with how it has been implemented. I
have some ideas on how things could be improved and I'm experimenting with a
few ideas, which I plan to release if they bare fruit. As part of this
process, I'm also trying to document the interface with the TTS drivers. While
I'm hoping this will identify how to best improve the espeak integration, I'm
also hoping this will make it easier to identify the possibilities for adding
a speech-dispatcher/openTTS interface for emacspeak. At the very least, I'm
hopeful this may provide information that will make it easier for other TTS
backends to be added to emacspeak. 

I expect it will be a while before I have much of any substance to share.
However, once I do, I'll be writing it up and distributing to the list for
comment and improvement. 

Tim

 

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help".