SSIP questions

[Trevor Saunders]

Hi,

On Sun, Sep 19, 2010 at 05:26:38PM +0200, Boris Dusek wrote:
> Hello,
> 
> I was reading the SSIP specification in doc/ssip.texi and had come to a few
> points where I did not fully understand what was being said.

yes, I think a bit of this spec could be clearer too.

I have an additional question, and share some of yours.

I note that it is possible for one client to set parameters like rate /
pitch / synth of another client at any point.  So if there are clients a
and b a can set the pitch client b uses.  I've been working on a ssip
client for android, and supporting that means I have to store client
settings in publicly which is slightly inconvienent, and to me atleast
silly.  So my basic question is does anybody have a use case for this
behavior?  and what purpose does  it serve?

> 1. Each message queued returns a msg_id. Is there a value range for msg_id 
> that
> must be supported by the clients? (like all 64-bit unsigned)

 well, speech dispatcher seems to use a guint to store it which iirc is
 32 bit unsigned.  I'd don't see any reason not allow it to be 64 bit,
 but I'm not sure how big a deal wrap around would be for clients.

> 2. Default message priority is mentioned as applying to messages with no
> priority explicitely specified, but this default priority is not defined in 
> the
> text. Is it an omission, or is it implementation-defined?
> 
> 3. Priority "progress" - it is said there that Speech Dispatcher detects that
> the progress message is the last one by waiting. Do I understand correctly 
> that
> that the specification means that there is some (possibly
> implementation-defined) timeout amount which the Speech Server simply waits to
> verify no other progress message arrives from the same connection and then
> speaks the progress message?

not sure, I thought the idea was that you dequeue'd all of the messages
and only spoke the last one, but even that seems huristic since there
could be progress messages for different things.  I'm really not sure
how to write a good way of doing this for a spec.

> 4. (just a thought) the image "figures/priorities" could list the "Important"
> priority also as "Doesn't interrupt itself")
> 
> 5. What is the relation between blocks and e.g. SSML? Can one do what the 
> other
> can't?

I've been thinking the purpose of blocks was to atomically set
parameters like rate and speak a message, so the cient could gaurentee
the right parameters are used.  Somewhat related to my question if you
don't use a block here then between you setting the rate for example,
and you speaking a message another client can come in and set your rate
to something other than what you wanted.

> 6. Regarding message blocks being treated as a single message:
> 
> I made this experiment:
> 
> 01:A: SET SELF PRIORITY text
> 02:A: BLOCK BEGIN
> 03:A: SPEAK
> 04:A: first text
> 05:A: .
> 06:B: SET SELF PRIORITY important
> 07:B: SPEAK
> 08:B: important message
> 09:B: .
> 10:A: SPEAK
> 11:A: second text
> 12:A: .
> 13:A: BLOCK END
> 
> block is began by client A on line 02, with priority set to "text" on line 01.
> First part of the message block is spoken after line 05. On lines 06-09,
> client B sends message of priority important which should cancel the currently
> spoken block from line 02. Yet second part of the block said by client A on
> lines 10-12 is still said, even though the whole block should have been
> cancelled.

No idea, I've never tried to test things like this.

> 7. The definition of parameter CAP_LET_RECOGN says that when the capital
> recognition mode is "spell", the capital letters are spelled "using the table
> set as CAP_LET_RECOGN_TABLE". I however did not notice what spelling "using a
> table set" means, and also have not noticed what CAP_LET_RECOGN_TABLE is.
> 
> 8. line 1158: event RESUME can be followed be either event END or RESUME.
> My question is: It cannot be again followed by event PAUSE?

imho the message is already paused, how can it be paused again?  It
should recieve a message at the next change in status, and I don't think
pause -> pause is a change.

> 9. Scope of event notifications. E.g. with
> SET SELF NOTIFICATION ALL on
> does the "SELF" mean:
> 
> a. notifications for message queued by any client will be sent
> to this (SELF) client
> b. notifications of messages queued by this client (SELF) will be sent
> to every client
> c. notifications of messages queued by this client (SELF) will be sent
> to this (SELF) client
> 
> I guess c. is probably right, but am not sure.
> 
> 
> 
> Sorry for flooding the list with so many questions, I hope somebody will be
> able to enlighten me.

no worries, you raised questions that should be answered.

Trev

> I also discovered a few typos/omissions/unclarities in the documentation, so I
> will post a patch fixing those shortly.
> 
> Boris
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20100919/c4338cec/attachment.pgp>