- From: Joseph Berkovitz <joe@noteflight.com>
- Date: Wed, 24 Jul 2013 14:55:17 -0400
- To: "public-audio@w3.org WG" <public-audio@w3.org>
- Message-Id: <E802BCE0-8C34-4DE6-8AFE-04488A4D013D@noteflight.com>
Prompted by something Jussi said this morning, I wonder if decodeAudioBuffer() doesn't have some other built-in disadvantages for processing XHRs besides the extra buffer copying overhead that he pointed out: - XHR response headers for the content MIME type are not available to the decoding process, so the data alone must supply information on what what codec to use. This may not be an issue to implementors, but I believe that the <audio> tag is sensitive to MIME types in some cases, and I wonder why decodeAudioBuffer() would be any less interested in that information. - There is no possibility of decoding incoming data on a pipelined basis as it arrives. I do not suggest we perturb the current API. I am just wondering if it is worth at some point introducing an additional decodeAudioURI() call that takes a URI, not an ArrayBuffer. I will pass on the debate over whether it should return an AudioBuffer or, as Jussi suggested, audio data in typed arrays. Best, . . . . . ...Joe Joe Berkovitz President Noteflight LLC Boston, Mass. phone: +1 978 314 6271 www.noteflight.com "Your music, everywhere"
Received on Wednesday, 24 July 2013 18:55:39 UTC