Re: Protocol for speaking daemon (comments expected)

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

-----Original Message-----
From: Bryan Smart <bsmart@pobox.com>

>>To synchronize speech, a 'wait' command can be used which returns a
message
>>when the specified message 'id' has been 'spoken'.  Hence, a synchronized
>
>Also, the wait command should have some kind of time out parameter which
>can notify the client if the server is unable to catch up to its message in
>the queue before the specified time passes.  Of course the query command
>that you mentioned could check this, but it might be nice to let the say
>command return a message specifying that the command has timed out.


True, the wait should timeout and have a failure response option if that
happens.

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


The best suggestion I have heard for this is to build multiple 'priority'
queues to feed into the TTS engine.  The say command can then have something
like "say pri=x" to select a specific queue.  Personality can be achieved by
specifying other overrides as well in the say command, such as for voice
(male/female).

>>set commands can be introduced to specify global parameters for a session,
>>such as: set language = English.
>
>I think that the pitch, volume, and other similar settings should be
>controlled at this point.  Also, as all synts have differing ranges of
>values for each parameterh, percentages might be useful.


Yes.  I agree.

>>Another obvious command would be query <msgid> to query the current status
>>of a message.
>
>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.

Assuming the TTS 'maps' index status into the control record, yes, this
could be
achieved.  One should also be able to specify a 'pause' to pause the
currently spoken text, perhaps either at a specific index point, or at the
next 'natural' break as deterimed by the TTS itself.  The latter would be
far more useful.

>>The "say" command can have options, such as to specify mode (literal,
spell,
>>or speak), pitch and speed (assuming the tts supports it), etc.
>
>These should be realative to the current settings (allowing a slightly
>lower or higher pitch than the default, using a slightly louder or softer
>volume, and so forth).


Or perhaps, either offset from the current defaults (+/- %) or absolute.
Hence, "say volume=-10" vs. "say volume=20".  But yes, relative (scaled) %
values probably makes the most sense.

>I'm not sure of the best way to do this, but there should be some way that
>the 'say' command can specify different personalities when speaking text.
>These, of course, would probably be different voices on the Dec-Talk, but
>you should be able to provide pitch, sppeed, volume, voice, and voice
>control (several synths support different voices) which have values
>realative to those defined by the set commands.
>
>Finally, it may be useful to put all of the synthesizer definitions in a
>'synthcap' or similar file.  This would provide something analogus to the
>SSIL standard system under Windows.
>
>Bryan


Any given server serves one 'engine', hence, a command to return the
capabilities of the given engine would probably accomplish this.  Another
thought might be to add a 'UDP' option to the server, so one can, for
example, broadcast a UDP 'request' to all TTS servers on a given subnet
specifically to look for a 'german' speaker, and then use that to connect to
the first responding TCP-SPEAK server capable of serving spoken 'german',
for example.


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