Re: How do screen readers work when there's a console and a normal window?
I'll just throw my opinions into the mix here in order the better to keep this discussion nice and inflamed.
My usual screen reading rate is about 275 WPM; sometimes it's faster, but it's rarely slower. I appreciate natural reading speeds because I enjoy savouring the content. I do realise that other blinks are happy to go faster, but I think I (and, frankly, many others) can afford the luxury of slower speeds.
I do agree with Camlorn, though, that it is a mistake to assume that the sensibilities of the sighted make any sense to blind people, or vice-versa, in the matter of concatenative vs formant synthesis. You're trying to judge the quality of a TTS synthesiser by how "Natural" it sounds precisely illustrates the problem; accuracy and speed are higher up on the list than "Naturalness", at least in typical screen-reading applications (but ironically, often not in games, which usually only output short, predictable and oft-used sentences). On the other feeler, I dislike eSpeak as compared to Eloquence--both are formant. As a Mac user and now using "Alex", which is essentially a concatenative TTS with go-faster signal processing not normally found in such synthesisers, I still miss Eloquence, even though Alex is among the very best such synths I've used. Microsoft's newest speech platform voices come very close too, though given the choice I'd stick to Eloquence again. If I were running you're game, I'd just install the older SAPI-enabled versions of the Nuance voices, and use those; they'd do fine. And on Linux, I'd use whatever worked--probably eSpeak.
Yes, ag_say is part of (older/obsolete versions of) AudioQuake and not expected to be on anyone's machine that doesn't use it, but really, it sounds to me like you'll be alright coding to the SAPI platform API yourself. A tip for you though, we only used C++ because M$ can't put a proper accessor declaration together for the API header files. COM is a bitch if you're a straight C programmer, but I trust you'll figure it out. Well, I hope you do, anyway … The ag_say source is available and it's GPL--feel free to use it if it helps you. It takes the stuff to say on stdin. I forget, for the moment, how we identify "Next string interrupt" but we translate that into the appropriate SAPI calls.
I've never used non-hardware Linux TTS, so I defer to some other, better authority on the subject. I would keep your eye out for that universal magic bullet that nobody's written yet though, just in case.
Good luck in your endeavours.
Edit: listen for yourself to Alex. Listen to the different rates.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
