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

Re: Decoding audio w/o an AudioContext object

From: Marcus Geelnard <mage@opera.com>
Date: Fri, 17 Aug 2012 21:27:52 +0000
Message-ID: <20120817212752.ji81denwag008s0s@staff.opera.com>
To: Chris Wilson <cwilso@google.com>
Cc: Chris Rogers <crogers@google.com>, public-audio@w3.org
Citerar Chris Wilson <cwilso@google.com>:

> On Fri, Aug 17, 2012 at 10:43 AM, Chris Rogers <crogers@google.com> wrote:
>> On Thu, Aug 16, 2012 at 11:29 PM, Marcus Geelnard <mage@opera.com> wrote:
>>> An alternative could be to pass an optional resampleTo argument to
>>> decodeAudioData() and createBuffer(), just as with mixToMono, to let the
>>> developer decide which sounds to optimize for 1:1 playback.
>> Yes, this could be possible as an optional argument.
> That was my reaction - that we should add control over the resample as an
> optional argument - but resampling should still be the default (i.e. it
> should be a "dontResampleToContextRate" flag [and no, that was not a
> proposed name]).  Otherwise, we're just going to cost perf in a large
> number of scenarios.  You're not usually going to care about getting the
> precise audio bits as much as you are going to care about getting good
> sound quality and low performance impact.

I agree. However, that does not solve the issue of decoding an audio  
asset without an AudioContext instance. So back to my original question:

Given that decoding functionality can be useful without an audio  
context, would it make sense to change the interface or add a new  
similar interface that permits decoding audio files w/o an active  
audio context?

If not, I'd go with your proposal of adding an optional boolean  
argument, since at least it would allow for 1:1 decoding even though  
you'd need to create a dummy audio context for accessing the  

> By the way, what is the use case for mixToMono, and why is it not available
>>> as an argument to decodeAudioData().
>> Yes, I know, the synchronous method is older and not consistent.  We might
>> even consider removing it from the spec since async is better.
> Heh.  You know, given that the two methods were named so differently, I
> didn't even realize the synchronous equivalent to decodeAudioData() was
> still in the spec.
> +1 to removing the synchronous method (that is, removing the
> createBuffer(ArrayBuffer buffer, boolean mixToMono) call.)

+1 on that too.

Received on Friday, 17 August 2012 21:28:24 UTC

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