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

Re: decodeAudioBuffer, XHR and MIME headers

From: Jens Nockert <jens@nockert.se>
Date: Wed, 24 Jul 2013 23:19:18 +0200
Cc: "Mandyam, Giridhar" <mandyam@quicinc.com>, Joseph Berkovitz <joe@noteflight.com>, "public-audio@w3.org WG" <public-audio@w3.org>
Message-Id: <99A1A754-3E80-4CBF-BC66-3DA64883F845@nockert.se>
To: "K. Gadd" <kg@luminance.org>

On 24 Jul 2013, at 23:07, "K. Gadd" <kg@luminance.org> wrote:

> Not to sidetrack, but 'streaming' is the key here. I've seen multiple mentions on this list (in particular re: the race condition/memcpy discussions) of the importance of being able to process large amounts of audio, and in that scenario having to download an entire 50MB of audio into a buffer before passing it into decodeAudioBuffer to decode all at once into another buffer is suboptimal. I said 'streaming' because being able to download and decode an MP3 in chunks of say 128kb at a time has lots of benefits - reduced memory usage, reduced latency before playback can begin, etc.

Streaming is the key here, but I cannot really understand why the MIME-type is important?

Almost every file is going to have an incomplete and/or useless MIME-type that will require sniffing anyhow. For useful (read, not audio/basic, or audio/L24) formats, you will only get the container type (audio/mp4, audio/ogg, audio/mpeg, audio/vnd.wave), and that should be trivial to sniff from the binary anyhow?

Jens Nockert
Received on Wednesday, 24 July 2013 21:19:50 UTC

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