Re: Protocol for speaking daemon (comments expected)

[Jan Hubicka <hubicka@atrey.karlin.mff.cuni.cz>]

> >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.
I think that fourth one (opetional) should be also usefull. It should be
used for example for keyboard echo, informations about work in prograss etc.
So they will be sent to output just in case no other output is active...
> 
> >> 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
I think this should cause problems with software syntetisers, wich wants
to know whole sentense to make better output (bprozology etc...)
Sending output in separate words should make problems here...
> 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

-- 

---
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