Subject: RE: [Speechsc] Recognizer queueing versus synthesizer queueing

From: "Reifenrath, Klaus" <[email-masked]>
Date: Fri, 3 Jun 2005 12:45:29 -0400

Hi,

I need to think about it. The use-case was a hotword recognition followed by
a normal recognition without loosing any audio data between these
recognitions.

Klaus 

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Freitag, 3. Juni 2005 17:46
To: Dave Burke
Cc: [email-masked]
Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queueing

On Jun 3, 2005, at 11:27 AM, Dave Burke wrote:

> It's probably worth pointing out that SPEAK and RECOGNIZE are not 
> really anti-symmetric since (a) RECOGNIZE requests typically require 
> the audio input to be synchronised with the recognition request and 
> (b) subsequent recognition actions normally depend on the results of 
> previous recognition action(s).
>
> I don't think queuing of RECOGNIZE requests is useful and by removing 
> it altogether we also get consistency with RECORD.
>
That works for me. The current machinery for recognize queueing is, well,
peculiar, and if we don't need it I'd just as soon get rid of it.

Let's see how others feel first.

Dave.

> Dave
>
> ----- Original Message ----- From: "David R. Oran" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, June 03, 2005 3:16 PM
> Subject: [Speechsc] Recognizer queueing versus synthesizer queueing
>
>
>
>> For some reason that escapes me these work completely differently.
>>
>> The reasons may be historical, or possibly because we thought   
>> queueing of requests processing media input were different from   
>> requests processing media output.
>>
>> To refresh memory, SPEAK requests are queued when the client issues  
>> one while a current SPEAK is active. If the current request is  
>> canceled for any reason (stop, cancel-on-barge-in,
>> etc.) the pending  SPEAK requests are nuked, and the completion 
>> response for the  cancelled SPEAK contains a header with the request 
>> id's of the other  requests in the queue that are now history.
>>
>> In RECOGNIZE, there is a header (cancel-if-queue) saying whether or  
>> not to cancel the current request if the client tries to queue  
>> another one. If a request is cancelled, the pending requests are also  
>> canceled but each returns a separate completion event. For some  
>> reason this header is defined as mandatory rather than having a  
>> default value.
>>
>> It seems at a minimum inelegant, to have this disparate machinery,  
>> and quite possibly a pain for servers which have a single scheduler 
>> implementation for their different resources to have to implement two 
>> entirely different schemes, not to mention clients which really  
>> should be simple and not have to worry about this kind of 
>> inconsistency.
>>
>> If it's too late to change this, I suppose we can live with it.
>>
>> If the WG will entertain a technical change, let me suggest that the 
>> other resources adopt the scheduling scheme used by SPEAK, since it's 
>> simpler, fully general, and well-described in the spec (the recognize 
>> scheme has some pretty tortured language to explain what's supposed  
>> to happen). If we do this, the cancel-on-queue header goes away and  
>> the active-request-ids header gets adopted by the other resources.
>>
>> I'd probably move the material on request queueing to the common   
>> protocol section if we go this route, rather than repeating all the  
>> stuff in each resource.
>>
>> Please respond with views, because I don't want to adopt such a   
>> change lightly.
>>
>> Dave.
>>
>> _______________________________________________
>> Speechsc mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/speechsc
>

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Brett Gavagni <[email-masked]>
Date: Fri, 3 Jun 2005 15:49:26 -0400

I would agree for the removal of queueing RECOGNIZER requests.

What application scenario would require this support? 

If an application has determined that hotword mode is preferable (due to 
noisy environment, for example), why would it switch to normal mode and 
eventually exit due to nomatch?

VoiceXML 2.0 has been clarified that in the hotword bargein scenario, a 
nomatch should not be a collected result after prompts have been played. 

http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml4.1.5.1

4.1.5.1 Bargein type
hotword 

The prompt will not be stopped until a complete match of an active grammar 
is detected. Input that does not match a grammar is ignored (note that 
this even applies during the timeout period); as a consequence, a nomatch 
event will never be generated in the case of hotword bargein.

Thanks,

Brett Gavagni 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/
[email-masked]

"Reifenrath, Klaus" <[email-masked]> 
Sent by: [email-masked]
06/03/2005 12:45 PM

To
"'David R. Oran'" <[email-masked]>, Dave Burke <[email-masked]>
cc
[email-masked]
Subject
RE: [Speechsc] Recognizer queueing versus synthesizer queueing

Hi,

I need to think about it. The use-case was a hotword recognition followed 
by
a normal recognition without loosing any audio data between these
recognitions.

Klaus 

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Freitag, 3. Juni 2005 17:46
To: Dave Burke
Cc: [email-masked]
Subject: Re: [Speechsc] Recognizer queueing versus synthesizer queueing

Dave.