- From: Marcus Geelnard <mage@opera.com>
- Date: Fri, 17 Aug 2012 21:27:52 +0000
- 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 functionality. > 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. /Marcus
Received on Friday, 17 August 2012 21:28:24 UTC