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.
