Re: Protocol for speaking daemon (comments expected)

["David Sugar" <dyfet@tycho.com>]

-----Original Message-----
From: Jan Hubicka <hubicka@atrey.karlin.mff.cuni.cz>
To: blinux-list@redhat.com <blinux-list@redhat.com>
Date: Monday, January 05, 1998 3:30 AM
Subject: Re: Protocol for speaking daemon (comments expected)


>> Say commands should also have some kind of priority indicator.  For
>> example, status messages should be given a higher priority than just
>> regular text.  E.G. While reading a document, status messages should be
>> spoken as soon as they are available (perhaps using a different
>> 'personality' -- see below).
>Yes, priority is quite significant, I think. IMO there should be defined
>something as following priorities:
>urgent
>normal
>low
>optional (say just in case nothing else is spoken....)

Really, there is not likely to be that much application demand on TTS.  I
would argue three priorities would be enough for virtually all situations;
high, base (default), and low.  Hence, you can put yourself above or below
the 'default' priority most applications would use.

>> Similar to the query command (or perhaps part of it), you should be able
to
>> not only learn the status of a message, but determine the currently
>> speaking message, and, if possible, obtain more definitive information
with
>> regards to your exact position in the message.  This would make things
>> similar to indexing on the Dec-Talk possible.
>Well, determining possition in messge should be quite complex at
non-dectalk
>stuff (like software syntetizers...) so it should be made as optional or
>something...

In the implimentation I am doing, the TTS engine passes a message back to
the server as it parses each 'chunk' of the posted 'say'.  Hence, if the TTS
is build to speak 'words' descreately, it would send a marker back at the
end of each spoken word.  Similarly, a phrase or sentance based system would
report current position for each phrase or sentance that has been spoken.
Indexing, then, is really an incremental measure of the TTS's parsing of the
current text being spoken, and is not used to absolutely index each and
every character byte descreately proccessed within the text by the TTS
engine.

An interrupt request is submitted to the TTS engine by the server when one
wants to 'interrupt' the currently spoken text, and the TTS will then return
the 'final' index of the last spoken 'component' of the current message.
This marker is chosen by the TTS where to break up the text, and so one can
assume incomplete phrases can be kept from being split, or, at least spoken
words.  The current message is then returned to the queue with the 'index'
pointing where to continue, as chosen by the TTS engine.



---
Send your message for blinux-list to blinux-list@redhat.com
Blinux software archive at ftp://leb.net/pub/blinux
Blinux web page at http://leb.net/blinux
To unsubscribe send mail to blinux-list-request@redhat.com
with subject line: unsubscribe