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 EbermanSpeechWorks-----Original Message-----Hello,
From: T [mailto:email@example.com]On Behalf Of vincent ribiere
Sent: Monday, March 05, 2001 5:44 PM
Subject: Prompt interface question
I have a question on the prompt interface and more particularly on the VXIpromptQueue
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
Does it make sense ? Can someone help me interpreting the spec on this particular point ?
Thanks in advance,Vincent
This page is maintained by
Alan W Black (firstname.lastname@example.org)
speechinfo.org is hosted on a machine donated by VA Linux Systems