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

Re: [web-audio-api] decodeAudioData should accept a mime-type (#7)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:26 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/7/24244121@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=18510#9) by Ehsan Akhgari [:ehsan] on W3C Bugzilla. Tue, 28 Aug 2012 14:37:20 GMT

(In reply to [comment #9](#issuecomment-24244116))
> (In reply to [comment #8](#issuecomment-24244108))
> > I would also prefer decodeAudioData to accept a non-optional mimeType argument,
> > and I think we raise an error if the mimeType argument is not supported by the
> > engine.  The reason that I would advocate for this change is that the audio
> > codecs supported by each engine (potentially on each platform) is different,
> > and that makes sniffing even worse than it already is.
> 
> Can you clarify how varying codec support between browsers and platforms make
> sniffing any harder? AFAIK, none of the formats supported by any browser are
> hard to sniff or possible to mistake for another supported format.

They won't make sniffing harder -- it just makes people rely on sniffing potentially multiple audio streams, which means that the browser engine needs to download the first few kilobytes of all of them until it finds one which it can decode.

The idea that I'm going after is very similar to the HTML5 source element.  The source element allows the browser engine to select the encoding that it supports *without* needing to download all of the available resources and sniff them.  If decodeAudioData takes a mimetype argument, then the browser engine can also avoid having to download the resource just to find out that it cannot decode it.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/7#issuecomment-24244121
Received on Wednesday, 11 September 2013 14:29:54 UTC

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