RE: Prompt interface question

["Brian Eberman" <brian.eberman@speechworks.com>]

The semantics of the design are that the call is non-blocking and it is the responsibility of the platform to fetch the prompt via HTTP and then actually queue the prompt.  Wait is blocking and can be used to return error conditions.  The other blocking call is Recognize in the VXIrec interface. 

 

To get finer grain control the interface is extended for release 1.5 which should be out soon.  The prompt interface will have a Play and Queue.  Queue is still non-blocking but doesn't trigger the play.  Play start the play and is non-blocking. Again Wait returns error conditions.

 

I've attached the proposed interface for comments. 

Brian Eberman

SpeechWorks

 

-----Original Message-----
From:  T [mailto:vxi-discuss@metronomicon.com]On Behalf Of vincent ribiere
Sent: Monday, March 05, 2001 5:44 PM
To: speechworks
Subject: Prompt interface question

Hello,

I have a question on the prompt interface and more particularly on the VXIpromptQueue
API:
the documentation says:
"Queue prompt for playing. This call is non-blocking. By default, a prompt added to an empty
queue starts playing immediately."

I'm wondering why this call is non-blocking ?
In the case the sound file is local, I understand VXIpromptQueue can return a result right away if
there is a problem (e.g."file is not there").
But if the prompt interface uses HTTP or even more elaborate protocols (e.g. RTSP), shouldn't it wait until
no exception is thrown to continue (e.g. there may be a few messages exchanged between the
TTS server and the VXML server until the TTS has started playing the file so we need to block until
then).

Does it make sense ? Can someone help me interpreting the spec on this particular point ?

Thanks in advance,

Vincent

 

 
 
 

Attachment: VXIprompt.h
Description: Binary data