[laptop-accessibility] Your requirements from a speech-server as a developer

[linaccess at yokoy.de]

hi,

first excuse my not so well english. I have problems to write down my thoughts in a accurate way using a foreign language...
 
Hemant, some background to ELIZA that I posted to the mailinglist.
I did a fast hack about implementing espeak but not using the speech server to ELIZA. It was the birthday of Joseph Weizenbaum, the initiator of ELIZA in 1966 and it was a dirty hack to be just in time:-) 
My coding level is near zero and I am totaly new to python, please have mercy. 

#SpeechServer
Indeed, the best way to use TTS is a speech server.
I did not have time to play with the speech server, yet. But I read http://wiki.laptop.org/go/Screen_Reader properly. As I understand the Screen_reader as mentioned on the wiki site it is more or less a espeak speech server frontend  with some nice features but not a screen reader. There is nothing wrong about that, maybe we could define for Sugar and the activities a proper UI guideline with fine ATIs. 
The known ScreenReader solutions of the UNIX world are far to big and slow to use them on the XO, IMHO. I am glad to hear about the Screen_Reader project aiming to fit the needs of Sugar and the activities and not to fit the whole UNIX world.
Some time ago Gnopernicus startet to be a fine ScreenReader and died because it was not scriptable and there was a promising proof of concept with ORCA. Three years ago ORCA stepped in and is far better, now, because the (software)world is not perfect. Due to the scriptability ORCA could manage the missbehavior of software. ORCA is fault-tolerant. Boon or bane, I don't know.
Anyway, I would like to see Screenreader and SpeechServer separated because a ScreenReader do not need a SpeechServer in any case. And vice versa. Just think about braille. And what I see on  http://wiki.laptop.org/go/Screen_Reader it is a SpeechServer but not a ScreenReader. Just rename the project?


To sum up my thoughts:
- The ScreenReader is a SpeechServer - rename it.
- a none scriptable ScreenReader is bad in the unix world but may be it is the right way on the Sugar desktop and the activities. In this special case it might be possible to work without a ScreenReader by defining a perfect UIG for the activities (big question mark)
- keep ScreenReader from SpeechServer separately.


Best regards,
yokoy



On Fri, 11 Jan 2008 23:06:14 +0530
"Hemant Goyal" <goyal.hemant at gmail.com> wrote:

> Hi Joshua, Tom, and Yokoy
> 
> Finally I have gotten time to start analyzing all requirements of the speech
> server.
> 
> I hope by now you have used and experimented with certain aspects of the
> present api of the speech-server (its mostly proof of concept, and we'll
> really do a through requirements analysis before defining the api).
> 
> As you all are working on self-voicing activities requiring speech synthesis
> you can provide me a good idea about your present requirements from a
> speech-server. FYI all your ideas currently use eSpeak separately, the
> speech-server will wrap around and abstract all that complexity providing
> you a clean and easy to use api.
> 
> Will it be possible for you to list out some of your requirements from a
> speech-server (present and maybe those that you may need in the future?)
> 
> It'll provide me a lot of information for deciding on the api for the
> speech-server.
> 
> I'd also appreciate it if you could keep me on cc wrt all your speech synth
> requirements.
> 
> Thanks!
> -- 
> Hemant
> 


--