W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 20039] The callbacks of the decodeAudioData API are underspecified

From: <bugzilla@jessica.w3.org>
Date: Thu, 29 Nov 2012 10:36:59 +0000
To: public-audio@w3.org
Message-ID: <bug-20039-5429-02Jz2q8OM8@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20039

--- Comment #1 from Chris Rogers <crogers@google.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 29 November 2012 10:37:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC