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

Clarification on the callback arguments of decodeAudioData

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Wed, 28 Nov 2012 19:13:01 -0500
Message-ID: <CANTur_7PmZ4DwC8JOZ_yj21hx4kvkfga7qWowgzN4jyfZsD+Jg@mail.gmail.com>
To: public-audio@w3.org
A while ago I filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20039but it has not
received any feedback yet.  Would you please review it and
let me know what you think so that I can proceed with the implementation in
Gecko?

Thanks!

(Description of the bug appears below.)

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"."

--
Ehsan
<http://ehsanakhgari.org/>
Received on Thursday, 29 November 2012 00:14:10 UTC

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