Re: "Protocol" requirement - Cancel request

This generally seems reasonable to be, but I would change the last
sentence of the description to: "For example, the web app must be able
to interrupt playback of synthesized speech and capture of audio for
speech recognition."

It shouldn't matter to the web application whether it actually
interrupts the synthesis or recognition, since what matters to the
application's user-visible behavior is just the audio output and
input. Requiring interrupting the speech processing itself would
restrict the design space unnecessarily, with the only benefit of some
bandwidth and processing savings.

I also dropped the "if speech is detected" part, since we already have
a barge-in requirement, and since web apps may want to interrupt audio
output for reasons other than barge-in.

/Bjorn

On Fri, Dec 10, 2010 at 8:50 PM, Young, Milan <Milan.Young@nuance.com> wrote:
> Summary – Web applications must be able to cancel speech requests which have
> not completed.
>
>
>
> Description – This requirement does not imply that the UA or SS behave as if
> the operation never occurred, only that continued processing terminates on a
> reasonable timeline once the cancel request has been received.  This feature
> is necessary for common speech operations like bargein.  For example, the
> web app must be able to interrupt synthesis if speech is detected, and must
> be able to terminate speech detection if the user doesn’t respond in a
> timely manner.
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Monday, 13 December 2010 10:27:44 UTC