W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:28:56 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/189@github.com>
> Originally reported on W3C Bugzilla [ISSUE-20039](https://www.w3.org/Bugs/Public/show_bug.cgi?id=20039) Thu, 22 Nov 2012 00:17:58 GMT
> Reported by Ehsan Akhgari [:ehsan]
> Assigned to 

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.

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?

3. "The ArrayBuffer can, for example, be loaded from an XMLHttpRequest with the new responseType and response attributes." should probably converted to "The ArrayBuffer can, for example, be loaded from an XMLHttpRequest's response attribute after setting the new responseType to "arraybuffer"."

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:31:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC