Subject: RE: [Speechsc] Queuing in ASR

From: "Andrew Wahbe" <[email-masked]>
Date: Mon, 24 Jul 2006 07:57:36 -0700

Well, typically you would want to limit the size of your hotword grammar
to get good accuracy, throwing all the commands into the hotword grammar
would most likely limit its effectiveness. Additionally, the
min/max-hotword utterance length features are based around the
assumption that you only have a few words in your grammar, allowing you
to further improve accuracy by restricting recognition to utterances
whose length is in the range you might expect for those words. If you
had a big grammar with all sorts of phrases in it, the length range
wouldn't be of much use. You also want to use short phrases/words for
hotword since you are only stopping the prompts after the utterance is
completed.
 
I have to ask if this is the only use case for this feature, though. I
think it would be better implemented as a new recognition type, say
"wake-up" recognition, that specified a special wake-up-word grammar in
addition to the "normal" grammars. This mode could send a
START-OF-SPEECH when the wake-up word was detected (allowing the prompt
to be stopped early), and might better handle cases where there wasn't a
long pause between the wake-up word and the command (from an
end-of-speech detection perspective, not just a "dropping audio"
perspective). Anyways, an "add-on" draft could define the type and new
headers, etc. Queuing the recognition isn't a great solution IMO since,
as Dave mentioned, you can't specify that the recognition should only be
run if the former was successful. I suppose that you could STOP the
second recognition in those cases, but it still doesn't seem like a
great solution. Anyways, are there other uses for queuing recognitions?
 
An event to signal when recognition was started may still be a good idea
(though I'm not a big fan of re-using START-OF-SPEECH for this) if we
want to get timestamp information about when recognition started (see:
http://www1.ietf.org/mail-archive/web/speechsc/current/msg01925.html).
In that discussion, I was assuming that you could put the timestamp on
the response to the RECOGNIZE request, but that solution delays the
response until you have received the audio that you are going to
process. I don't think that's such a great idea; a separate event is
much better.

Andrew

________________________________

From: Dave Burke [mailto:[email-masked]] 
Sent: July 21, 2006 4:46 PM
To: Reifenrath, Klaus, VF-Group; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Speechsc] Queuing in ASR

Thanks for the clarification.
 
Still a little puzzled as to the features merit. Couldn't you have
"Computer please check my inbox" as a hotword phrase and just have a
single recognition - especially as you can't make the second
recognitions grammar conditional on the first's result? I'm not sure
START-OF-SPEECH is so elegant here - e.g. you're not guaranteed it will
be generated if the user just says "Computer". Also, START-OF-SPEECH
doesn't correspond accurately to the PENDING to IN-PROGRESS transition
but rather with a max error of No-Input-Timeout.
 
Dave

	----- Original Message ----- 
	From: Reifenrath, Klaus, VF-Group
<mailto:[email-masked]>  
	To: Dave Burke <mailto:[email-masked]>  ;
[email-masked] ; [email-masked] 
	Cc: [email-masked] 
	Sent: Friday, July 21, 2006 7:30 PM
	Subject: RE: [Speechsc] Queuing in ASR

	The queuing for speech recognition resources was introduced in
the context of hotword recognition. Very often you want to start a
normal recognition after a hotword recognition without loosing audio
blocks between the two recognitions. E.g. a hotword recognition is used
to detect the wake-up  ("Computer") and a normal recognition to
recognize the following request ("Please check my inbox!"). If we cannot
queue recognition requests, the recognition resource will miss
meaningful audio blocks, because the client can start the next
recognition only after it received the recognition result. 
	 
	The START-OF-SPEECH event indicated that the next recognition is
started. 
	 
	Klaus

________________________________

		From: Dave Burke [mailto:[email-masked]] 
		Sent: Freitag, 21. Juli 2006 19:45
		To: [email-masked]; [email-masked]
		Cc: [email-masked]
		Subject: Re: [Speechsc] Queuing in ASR

		Good comments. I had also spotted the problem of
notifying PENDING -> IN-PROGRESS for the speechrecog resource. My
personal preference is to simply remove the queuing of RECOGNIZE
requests as I don't see any worthwhile value to this feature. It will
also be quicker than fixing it though that's just a nice side-effect.
Any vehement disagreements?
		 
		Dave
		 
		----- Original Message ----- 

			From: jakki sasidhar <mailto:[email-masked]>

			To: [email-masked] 
			Cc: [email-masked] ; [email-masked] 
			Sent: Friday, July 21, 2006 2:10 PM
			Subject: [Speechsc] Queuing in ASR

			Hi,
			    MRCP draft-ietf-speechsc-mrcpv2-10 is not
clear about the queuing of RECOGNIZE request at the ASR resource. As per
section 9.9, if the server receives a RECOGNIZE request and the ASR
resource is currently active with another request, then a 200 response
with PENDING state will be dispatched to the client. But once the ASR
becomes free and starts serving the queued request, it needs to indicate
this to the client. In the case of TTS, this is done by using the
SPEECH-MARKER event which carries a NULL marker and the state as
IN-PROGRESS. But for ASR, the spec doesnot define any such mechanism. 
			    Also, if there are multiple requests pending
at the client side, a STOP request defined for TTS can carry a list of
request ids to specify which all requests should be stopped. There is no
such provision in case of the STOP of RECOGNIZE requests.
			    Any comments on this will be appreciated.
			 
			Thanks & Regards,
			Sasidhar

________________________________

			_______________________________________________
			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