National Federation of the Blind
Research & Development Committee
4424 Brookhaven Avenue
Louisville, KY 40220
September 2, 1993
Mr. Buhrow proposes to develop with our help a Unix box with speech access.
His proposal is appended below. If you have advice or information that would
be useful to Brian, please communicate with him through our NFB-RD@nfbcal.org
listserver so that the rest of us can stay informed.
With this letter, I am appointing Mr. Buhrow as director of this project. We
will purchases the necessary equipment and cover other expenses from our R&D
budget.
If you believe that there are better choices than the Sun workstation
mentioned in his proposal, this would be a good thing to mention in a message
to him right away so that we can begin to procure the basic hardware.
I will be sending Brian further instructions when I return from a few days of
R and R in Chicago. Meanwhile, Brian, put together a parts list with
suppliers and prices.
Sincerely,
T. V. (Tim) Cranmer, Chairman
<cut here>
The purpose of this document is to outline the process by which we
research and produce a talking X terminal. The idea is that this terminal
would be a dedicated talking terminal capable of working as a standard
ASCII terminal as well as a standard X terminal. Speech capability would
be inherently part of the system regardless of the mode in which used it.
Although it would probably run under a Unix platform, the user of the
terminal would not be aware of the operating system. Also, this device
would be produced using standard PC hardware commonly available today!
The purpose of this document is to outline the steps necessary to get
the research and production underway. What process should we use to best
determine how to go about making this device? What specific modifications
would be necessary to get a working machine?
General description
I envision a machine running a spin-off of the Unix operating system
with a modified console tty driver which would allow speech to be installed
on the system and to be used on the system by a blind person to perform all
of the tasks the terminal might be asked to perform. These include logging
into the terminal, configuring the terminal -- along with its speech
configurations -- and testing the terminal to determine whether or not
there is a network fault somewhere. In short, a blind person should be
able to setup and use this device independently. That is, as independently
as any network device can be.
The talking X terminal should be able to speak ethernet, parallel,
and
serial. Although most X terminals are directly connected to their hosts
via ethernet, a serial interface would be necessary in order to allow the
user to use the full capabilities of his X terminal over a sl/ip line. The
reason for the parallel port is to allow users to setup printers on their
terminals -- as any sighted user would.
1. Determine the best platform on which to work.
Because X-Windows is primarily used on the Unix environment and
because Unix is a true multi-tasking operating system which would allow
multiple activities to be going on at once, it seems that this platform is
the best one to use for this technology. Because we are working with a low
budget, I recommend that we use one of the freely distributable Unix
packages now available on the InterNET. We certainly could use a
proprietary package from another company, but then we would be reliant
on that company to support our platform or, if they decided not to, to
convert our software to another platform. With the freely distributable
Unix's, we would have access to the source code we used to make our
products for as long as our products were receiving active attention.
There are two freely distributable Unix packages available today.
Linux, written by Lineus (something) in Finland, is copyrighted by him and
is highly regarded by many people in this country. It has a wide following
and has had a large number of applications written for it.
386BSD, the other freely distributable Unix was written by William
Jollitz from the University of California at Berkeley Computer Science
Department, in conjunction with the folks who wrote the Net/2
release of Berkeley's Unix operating system, has received much attention
from the students at UC Berkeley. It has much of the same functionality as
Linux, and, as of this writing, works far better with networks than does
Linux. I have spent the last four months conducting rigorous tests of the
386BSD product and feel that it is the best candidate for our attention.
2. Get the console to talk
The next stage of the game is to modify the console driver of the
chosen operating system to allow a screen reader program to be used on the
console in a transparent manner. The best solution would probably be to
put hooks in the console driver to allow the screen reader software to take
over the keyboard, and to see what is coming through to the screen so as to
be able to build an off-screen model.
The result should be that the screen can be examined through software
and with a speech synthesizer
The screen reading software should also be able to receive information that
other applications might direct at it. For example, when running the X
server, it might be useful to modify the X server such that it stuffs
information at the screen reader which then places that information in the
off-screen model. In other words, the screen reader should be able to
obtain information from the text-based console in much the same way the
current ones under DOS do, and it should be able to receive information
from other applications running on the system and incorporate that
information into a usable structure for the user.
One of the most important considerations for the screen reading
program (along with its speech driver) is response time. Because Unix is a
pre-emptive multi-tasking operating system where the kernel has complete
control of the system, it is hard to guarantee that a given process gets
processor time when it requests it. Thus, it is conceivable that when a
blind user presses the combination of keys to read the fifth line of the
screen, there could be a significant delay before the contents of that line
are spoken depending on the load of the system. One way to address this
problem is to say that because this is a dedicated terminal, there won't
ever be any other processes running on the computer to demand cpu time.
(This isn't strictly the case, but with the exception of the Kernel and the
and the X server, this would be the case). Of course, the X server could
be doing something quite complicated and require a lot of CPU time at once,
but in most cases this probably wouldn't be a problem. Another solution is
to put the screen reading software right in the console tty driver itself
(perhaps as a loadable kernel module) and so it would be able to demand the
CPU right away. There are semantic arguments for not stuffing applications
level stuff in the kernel, but given our requirements, this might not be a
bad idea.
3. X support.
Once the console is talking under text-based control. the job of
modifying the X server to get it to talk needs to be tackled. As I said
earlier, one approach might be to have the X server stuff data at the
screen reading software. If the screen reading software is built-in to the
kernel, then this could be done with a number of system calls. Look, for
example, at the APIs proposed by Berkeley Systems and MicroSoft for how
information might be passed between the two entities.
4. Future ideas
Once the idea can be shown to work for one platform, we could
continue
trying to port our code to other platforms. Most of the code, I imagine,
would be written in C or C++ and would be fairly portable between Unix
systems. For example, Sun's new operating systems have loadable kernel
modules and, if a kernel module were written for their operating system, we
might be able to use Sun Workstations as talking terminals as well.
Although there are many different flavors of Unix, they generally have some
historical relation to either Berkeley's Unix or AT&T's Unix (the original
egg anyhow). If we build our prototype on the BSD platform and then port a
version over to the Sun or Linux platform, it is a fairly small step from
that point to supporting almost all of the large vendor's Unix boxes. By
this I mean that from Berkeley to Sun is a long step and from, say,
Berkeley to Ultrix, DEC's contribution, is relatively small. So also is it
from Sun to SGI. But, first things first.
Brian buhrow
September 2, 1993
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST