Re: Poor error events in SpeechSynthesis API

Eitan,

I agree, I'd like to see error codes.

Glen suggested these:

          "cancelled",  // by calling cancel() -- not sure if necessary.
          "audio-hardware",  // computer audio hardware not available or
not configured
          "network",  // network error
          "not-allowed",  // similar to reco:
https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-sre.notallowed
          "service-not-allowed",  // similar to reco:
https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-sre.servicenotallowed
          "language-not-supported"  // unsure if necessary, since should
use getVoices()

Other possible errors I thought of:

          "interrupted" // similar to cancelled, but fired when it was
partially spoken, vs just queued and hadn't started
          "busy" // audio hardware is available, but another app is
speaking, tying up the system's speech system
          "voice-not-available" // this may happen if a voice disappears
between when it's returned in getVoices and when the app tries to use it -
or if the voice appears to be available but fails to initialize. either
way, it implies that trying another voice might work

- Dominic


On Thu, Feb 7, 2013 at 2:14 AM, Eitan Isaacson <eisaacson@mozilla.com>wrote:

> Hello.
>
> The speech recognition API has a very detailed SpeechRecognitionError
> event. But synthesis only has an opaque "error" event type, with no
> further details on the type of error or a human readable message. I
> recommend adding a 'message' attribute to SpeechSynthesisEvent that
> should be used ONLY on error events. Furthermore, the 'name' attribute
> could be used to specify the error type from a limited corpus, similar
> to ErrorCode in SpeechRecognitionError.
>
> Cheers,
>   Eitan.
>
>
>