[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Segmentation Fault with Emacspeak/Eflite
- To: email@example.com
- Subject: Segmentation Fault with Emacspeak/Eflite
- From: Richard C Bilson <firstname.lastname@example.org>
- Date: Thu, 10 Oct 2002 12:41:36 -0400 (EDT)
- Resent-Date: Thu, 10 Oct 2002 12:47:49 -0400 (EDT)
- Resent-From: email@example.com
- Resent-Message-ID: <"EtI1g.A.gmF.a3ap9"@hub>
- Resent-Sender: firstname.lastname@example.org
I'm doing some volunteer work for a community organization that is
attempting to refurbish some old computers to run Linux and give them to
those in need in our community. Some of these people are visually
impaired, and we like the idea of Emacspeak as a way to make these
computers accessible. Our only problem right now is that we can't make it
work on a consistent basis.
We're relying on sofware synthesis, specifically flite/eflite.
I understand that ViaVoice is no longer (officially) available, and I
don't know of any other alternatives. We're experimenting right now
on a P-100 -- flite is a fairly large drain on the CPU, but it can read
text just fine from the command line. Yes, it's a slow machine, but it's
typical of the machines that we have to work with.
Sometimes emacspeak works just fine. Other times it starts loading up
normally and then fails with the message "Process speaker not running".
When run as /usr/bin/emacspeak, this error also seems to inhibit reading
the .emacs file. Sometimes it will print that same error for just about
every keypress, other times some key press will cause it to wake up
(M-x often does this). Once it wakes up it works fine. We have tried
Emacspeak 15.0 and 16.0, but we get the same behaviour with either.
Being the intrepid programmer that I am, I sat down today to try and figure
out what's going on. What I found:
- if I (defvar dtk-debug 't) before loading emacspeak-setup.el, the
tts-debug buffer contains "Process speaker segmentation fault" a couple of
- if I examine the core file generated by eflite, I notice that it's
failing in the "finish" signal handling function, with sig=17 (SIGCHLD);
it fails because "lang" is null.
This seems to narrow down the possible locations where the problem occurs
(somewhere before "lang" gets initialized). I'm suspicious that there's
some kind of race condition in eflite, where it expects flite to be ready
to go but the slow processor causes a fatal delay. Unfortunately I don't
know enough pthreads to grok the eflite source, so I'm wondering if anyone
out there has any ideas, or has faced this problem before and solved it.
Emacs version 20.7.2
Emacspeak version 15.0
Eflite version 0.3.3
Flite version 1.1
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "email@example.com" with a
subject of "unsubscribe" or "help"