Re: Protocol for speaking daemon (comments expected)

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

-----Original Message-----
From: Luke Davis <ldavis@voicenet.com>


>Suggestion:
>
>On say: set up priarities such as:
>
>p=0
>p=1
>p=2
>p=3
>p=4
>p=5
>etc. (probably not that many)


Agreed.  I had not gone into details on the protocol spec, because I wanted
to float the overall concept first.  When I am back from Texas next week, I
plan to write a more formal and complete 'draft' specification for
TCP/SPEAK, and will add these suggesions (priority queue selection,
interrupt options, etc) into it.

>0 = Say it now; interrupt (clearing) next text.
>1 = Same, but speak rest of text when message done
>2 = Say after current.
>3 = Put on cuee.
>
>Default would be 3.


Option '1' can be achived by simply by selecting a higher priority queue,
and option '2' really is more a 'put me in front of the priority queue i
selected' kind of operation.  Hence, I would say queue=first or queue=last
effectivily is option 2 and 3.  Interrupting in the middle may require some
thought on how the 'server' interracts with the backend TTS, which I haven't
thought about yet :).  But barge-in can be interesting...

>Suggestion:
>
>Create an interrupt yes|no flag.:
>
>i=0
>i=1
>i=2
>...
>
>0 = This message can not be interrupted by anything.
> (Could be used for shutdown warnings, but could be abused)
>1 = Can only be interrupted by messages with p=0 or p=1.
>2 = Can only be interrupted by messages with higher priarity
> than is had by the current message.
>3 = Don't interupt anything.


This may be more complex than needed.  Interrupt requests should only
interrupt a message of the same priority or lower.  Hence, if one wants to
make a message only interruptable by pri 1 or 0 messages, one would select
the priority 1 queue for it :).  The option then can simply be
'interruptable=yes/no', which simply is used to indicate if the current
message is interruptable or not.

>Default would be 3.
>
>If this is done, then also do a cap I interrupt flag.:
>
>I=0
>I=1


>0 = This message can/should not interrupt anything.
>1 = This message should interrupt if it can.
> (in which case the lowercase i flag takes effect)
>
>The default will be 0.


Hmmm...

>Suggestion:
>
>A "textback" command.:
>
>Client Server
>
>say "this is a test"
>114568272
>
>textback 114568272
>This is a test
>
>Hense an application can determin something from history with out having
>it spoken.

But it probably should also include information on how it was 'spoken'
(pitch, voice set, etc), which could be returned seperately by the 'query'
command.  I already presume each TTS 'message' spooled out includes a 'text'
(body) and a 'control' record, which would hold the current 'default' values
of the server at the time SAY was issued (or the value of any single
utterence overrides specified in the say command).

>
>Reminder:
>
>I'd advise againced using a dot on a line by it self to end, due to
>conflicts when reading text.
>For example: a centense runs over, but only the period ends up on the next
>ine.
>There is more to say, but since the next phrase does not have a say
>command, the server will generate errors.
>
>So how about something like either EOF (ctrl-d), or ";\." (or something
>obscure like that).


This is a common problem in nntp also :).  The solution is either to make
sure the application never sends an empty line (just a '.'), which nntp post
programs (and older mailers) have traditionally done, or, yes, to choose a
different end of text indicator.  My thought of the '.' was simply to be
consistent with other existing protocols.

>Or:
>
>say [options]
>Help me linux guru, you're my only hope . . .
>\\say
>
>Or standard say:
>
>say [options] "text"


That would be an alternate option, though it leads to potentially 'long'
lines :).

>||
>
>say [options] <<end_of_text
>'Ice berg, dead ahead!'
>and:
>'Sorry ei didn't build ya a better ship, Mis Rose.'
>Are t phrases you'll here in "titanic": the most expencive (but very, very
>much worth it) movie of 1997/98!
>end_of_text
>
>Just some thoughts...



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