Re: Prompt interface question

[<voice@mercury.tgflinux.com>]

I think one reasons for supporting this queuing mechanism is
for "barge-in". I can start to queue up a list of prompts, then I can
block for other events from the user, such as DTMF or Voice Recognition
results. Once the user barges in, the queue may be flushed. 
This way of playing prompts also allows queuing:
 TTS prompts: TTS engine could synthesize while waiting to be played
 HTTP prompts for download
 Fetching of <value expr=> tags or other "fetched"/computed data 	

The queued prompts can be processed while previously queued prompts are 
being played. In the case that an exception occurs while retrieving a
prompt (HTTP, etc), the alternate text could be queued for playing.

I think the main reason for supporting queuing is to minimize the
time between retrieval and playing for prompts that aren't local files.

At least this is my interpretation of it. We've got about one more day
before our own system should be able to run using OpenVXI, Festival, and
Shpinx2.

p.s. 
didn't check my mail in time for your "DTMF" issue. I didn't realize
there was even that much traffic on the list.

Rick Smith
Software Engineer
www.tgflinux.com
rick@tgflinux.com

On Mon, 5 Mar 2001, vincent ribiere wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
>