Speakup and ViaVoice.

[Janina Sajka]

Brian:

These are very good points in your post. But there is another reason for
discussing this now, imho. Namely, design decisions made today might want
to comprehend the addition of a speech device which cannot, by its nature,
talk from the start. Maybe I'm wrong, but it seemsthis is an issue we
should air whether or not any software speech is wired in today or some
unknown tomorrow. future tomorrow day.

So, to the issues you raise. Let me go backwards ...

I'mfully in support of open source for numerous reasons I don't think
necessary to go into here. What I cannot support is the view, held by
some, that anything not open should be shunned. To me that argument is
just silly and awfully fundamentalist in a religious sort of way. I
suspect very few of us have exclusive GPL systems. I know I don't.

More to the point, imho, is whether or not Speakup should support synths
that don't talk from the beginning of the boot process. I argue they
should--at some future time, at least. When this should be prioritized in
is an issue aside from whether it should be support, in my view. First
things first.

So, why? Certainly speech from the beginning is one of the more attractive
and powerful features in Speakup. I love it myself. However, my needs
aren't defined by installing and debugging. I don't use Linux to use
Linux. I use it to do work of a personal and professional nature over and
beyond the construction of technology systems. So, it simply isn't always
the case that I care to hear all of those messages from the start. In
fact, I usually hit the numeric enter key to shut speech up. In fact, I do
this far more often than I listen to all of those messages. I would
warrant that most people shut up speech far more often than they sit and
listen to it in the boot process. So, it does not trouble me that some
particular output device would not support the debugging and installation
need. Other devices would continue to do so. Just as with the open source
issue, in my view, this is not an either or situation. Rather, I see it as
a both and situation. I believe it is reasonable to plan for and work
toward supporting the wider range of user needs.

If you've ever sat on airplane after airplane trying to respond to mail
and to write reports while having to tie a serial port to a
battery-powered synth (probably stuck in the seat pocket in front of you),
you'd probably appreciate software speech. If you've ever wanted to simply
pull your portable out of its bag, flip the lid open for a system resume,
just to jot down a thought or two, you'd appreciate not having to connect
that external device. In fact, if we're ever to get to a truly portable
unit with Speakup, we must have either an integrated hardware synth, or
software speech. Two pieces of hardware connected by a cable will never a
useful portable system make.

Please do not misunderstand me. I am not trying to set the priorities
here. I am simply trying to air the larger issues because, in my
experience, the more one comprehends these in making early design
decisions, the more extensible a system is. I would hope we wouldn't
disagree on that. So, I like the notion of /dev/synth. I rather even like
/dev/synth0, /dev/synth1, etc., etc, because I see value in having
multiple voices speaking different messages from different processes. I
also like supportfor switching synths without rebooting. But, I have no
position on whether this should hold up the next Speakup release. That's
not my point.

				Janina

 On Tue, 12 Dec 2000, Brian Borowski
wrote:

> There's been a thread about speakup and ViaVoice and writing the code to
> make this work.  I wanted to point out a few things about this idea, that
> are going to have to be worked out.
>
> *  ViaVoice is a software synthesizer and the kernel has to be running,
> and most of the other parts of linux have to be operational before
> anything can be done with a software synthesizer, unless it gets totally
> built into the kernel; that could make a kernel huge, and would also
> require that sound card stuff (there are very many sound cards out there),
> be loaded into the kernel as well.
>
> *  You would miss the real-time boot-up stuff from the kernel, a very
> important feature, in my opinion, especially when trying to figure out
> what is going on when something is not working as it should be, or when
> you're trying to build a kernel and something isn't quite working write.
> You could make use of the kernel message buffer to have the software
> synthesizer speak the startup messages after the fact, but if there was a
> failure during bootup; you would never get the opportunity to hear
> anything at all, because you'd never get the speech started up.
>
> *  Then, finally, there's another thing, the kernel is open source,
> speakup is open source, the information is available for the software
> synthesizer API, and perhaps, with some imagination, someone can figure
> out a solution for the above two points.  If someone really wants this
> badly enough, why can't they put some effort into coding for this project.
>
> There's more than enough work with the normal speakup development to keep
> a few Kirks busy, without even worrying about ViaVoice, so I suspect, that
> this is one of those projects that someone else will have to do.  If
> there's no one else to do it; it probably won't get done for a very long
> time.
>
> Brian Borowski
>
>
>
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>

-- 

				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

janina at afb.net
(202) 408-8175
http://www.afb.org/gov.html


The invention of the printing press has been named the crowning
achievement of the past millennium. Yet, electronic publishing will soon
eclipse it. Read our White Paper: "Surpassing Gutenberg" available at:

	http://www.afb.org/ebook.html

Are you developing software? Make it accessible to blind computer users.
Read http://www.afb.org/technology/accessapp.html to learn how.