[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using emacspeak with speech-dispatcher
- To: email@example.com
- Subject: Re: Using emacspeak with speech-dispatcher
- From: Milan Zamazal <firstname.lastname@example.org>
- Date: Sat, 07 Jan 2006 19:13:55 +0100
- Delivered-To: email@example.com
- Delivered-To: firstname.lastname@example.org
- In-Reply-To: <email@example.com.HOWL> (Lukas Loehrer's message of "Fri, 6 Jan 2006 21:54:54 +0100")
- List-Help: <mailto:firstname.lastname@example.org?subject=help>
- List-Post: <mailto:email@example.com>
- List-Subscribe: <mailto:firstname.lastname@example.org?subject=subscribe>
- List-Unsubscribe: <mailto:email@example.com?subject=unsubscribe>
- Old-Return-Path: <firstname.lastname@example.org>
- References: <email@example.com.HOWL>
- Resent-Date: Sat, 7 Jan 2006 13:14:00 -0500 (EST)
- Resent-From: firstname.lastname@example.org
- Resent-Message-ID: <fcCTcD.A.ajH.oTAwDB@mail>
- Resent-Sender: email@example.com
- User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
Interfacing Emacspeak with Speech Dispatcher may not be easy. Emacs
client to Speech Dispatcher was our first intended real use of Speech
Dispatcher and we naturally thought about writing a Speech Dispatcher
backend to Emacspeak. Emacspeak provided an extensive speech output
system for Emacs and it seemed to be a nice speech interface for testing
Speech Dispatcher in real use.
But after thinking about it carefully, we decided it was easier to write
a new Emacs client than to try to use Emacspeak with Speech Dispatcher.
I think the time has shown our decision was right.
What are the problems of making Emacspeak to work with Speech
Dispatcher? The basic problem is Emacspeak and Speech Dispatcher
architectures don't complement each other. We found the following
- Emacspeak contains a lot of TTS functionality. This is exactly what
Speech Dispatcher tries to avoid, it gets the burden out of the
clients. So significant part of Emacspeak would become useless. Of
course that wouldn't be a big problem, but the problem was how to
disable all the TTS processing performed by Emacspeak. That didn't
look very easy and we were somewhat reluctant to spend significant
effort on disabling software features.
- Emacspeak communication with servers was one-way only, from Emacs to
the server, at the time we thought about it. OTOH SSIP (the Speech
Dispatcher communication protocol) answers client requests. So there
was no way to get feedback or information from Speech Dispatcher.
Again, this is not a blocking issue, it could be solved by writing an
Elisp client library. But without TTS and server communication
framework Emacspeak would become quite reduced, while writing the new
library would mean a half the way towards new client.
- There was no apparent way to take advantage of the Speech Dispatcher
message priority model in Emacspeak. But this means one of the most
important Speech Dispatcher features and reasons why Speech Dispatcher
was written couldn't be used in Emacspeak. This was a serious issue
and one of the primary reasons we couldn't use Emacspeak for Speech
- Emacspeak didn't work with Czech very well. We were not much
successful with fixing that before. Additionally we could see no
apparent way how to make Emacspeak work well in a multilingual
environment, even with the Speech Dispatcher support. So we preferred
to work on a non-English clean system instead of fighting with i18n
- Debugging an Emacs speech system is no easy thing. The smaller and
simpler the debugged system, the easier the debugging job. I was
afraid of debugging such a complex system as Emacspeak is.
Based on such arguments we gave up on adding Speech Dispatcher support
to Emacspeak, in favor of writing new thin client. How our idea of
implementing a real Speech Dispatcher client in Emacs succeeded? I
think very well. Thanks to the use of Speech Dispatcher features
speechd-el is a complete speech output and Braille display Emacs client
containing totally less than 4000 lines of Elisp code (and this could be
even much less if a Braille dispatcher was available). Compare this
with the size of Emacspeak and you'll get the idea why using Speech
Dispatcher is something totally different than just adding a few speech
Since we have already decided not to interface Emacspeak with Speech
Dispatcher, we are naturally not directly interested in working on it.
But I can give you some advice at least.
First, please try to avoid duplicate work. If there is something we
could cooperate on, please don't forget to tell us.
Using speechd.el SSIP client library instead of implementing an SSIP
Emacspeak server is probably a good idea. If nothing else, this avoids
some obstacles of the one-way communication and can be useful for error
handling. If you need to enhance the library, I'd be glad to
incorporate your patches into it. BTW, Pierre, what are the voice
changing features you miss is speechd-el?
If you'd like to use any component of speechd-el, I recommend using the
CVS version of speechd-el. There are some changes in speechd-el, mostly
related to making it independent on a particular kind of output. The
CVS version is mature and by using it you avoid making changes in your
code after speechd-el 2.0 is released. Unfortunately the changes have
not been documented in the manual yet (which is the only major issue
blocking the release of speechd-el 2.0), but I can help you if you have
Actually speechd-el doesn't use SSML. But it should be easy to use
speechd.el with SSML, I think all what is needed is to add a command for
switching on/off Speech Dispatcher SSML support in speechd.el, which is
But note that SSML support is currently quite incomplete in
festival-freebsoft-utils. The upcoming festival-freebsoft-utils release
is less complete with regard to the SSML support than the last release,
for the sake of being less buggy and confused. Some important features
are to be added later, it's not easy to make them work in multiple
languages (Festival is very flexible, which is both its advantage and
Though both Emacs 21.4 and CVS Emacs are supported by speechd.el, it
works better with CVS Emacs, because it adds one feature important for
reliable two-way socket communication.
As for Emacs character set support, I don't think there are any serious
issues concerning speech interfaces there. I don't say there are
absolutely no problems (I'm aware about one unresolved character coding
bug, which can rarely appear in communication with BrlTTY in both Emacs
21.4 and CVS Emacs), but AFAIK there's nothing one should care about for
the purpose of multilingual support in Emacspeak or speechd-el.
Don't forget error handling is an important part of communication with
the server. We've met several annoying situations in both Emacspeak and
speechd-el, e.g. sometimes it wasn't easy to quit Emacs after
communication error with the server. I spent a lot of time on fixing
such issues in both the client library and the user interface of
And finally, I've just got another idea: Perhaps instead of making
Emacspeak work well with Speech Dispatcher it might be easier to look at
the suggestion the other way round and to write an Emacspeak emulation
for speechd-el? Well, it's just a quick idea :-). But it might be
worth considering, you might get full advantages of Speech Dispatcher,
Braille output, multilingual features, etc. immediately this way. Of
course it's dependent on your particular needs.
Anyway, feel free to contact us with any questions regarding Speech
Dispatcher and/or speechd-el on the Speech Dispatcher mailing list
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "firstname.lastname@example.org" with a
subject of "unsubscribe" or "help"
Emacspeak Files |
Unsubscribe | Search