Re: [web-audio-api] The callbacks of the decodeAudioData API are underspecified (#189)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=20039#0) by Chris Rogers on W3C Bugzilla. Thu, 29 Nov 2012 10:36:59 GMT

(In reply to comment #0)
> Here is a list of problems that come to my mind right now.
> 
> 1. It's not clear whether the callbacks have to be asynchronous or not.  For
> example, if for some reason the implementation decides that it's unable to
> decode the audio right away, should it just call the failure callback
> directly, or call it the next time that the execution hits the event loop.

I'm not sure I completely understand the question.  The decoding is meant to be asynchronous, so in some sense will not happen "right away".  So neither the success nor the error callback will be called directly, but at some later time (a later time in the event loop).  The failure callback should be called if there is an actual error in the decoding, meaning that the audio data is not one of the known and supported formats (depending on what the user agent supports), or that the audio data is corrupt.

> 
> 2. It's not clear what the AudioBuffer callback passed to the failure
> callback should contain.  For example, if the audio's type cannot be
> sniffed, what should be passed to the failure callback?  What if the source
> buffer doesn't contain valid samples and the decoding operation fails
> half-way?

I think it's best that there is *no* AudioBuffer in the failure case.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/189#issuecomment-24244733