- From: Ehsan Akhgari <ehsan@mozilla.com>
- Date: Tue, 4 Dec 2012 19:00:55 -0500
- To: Chris Rogers <crogers@google.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CANTur_5gmxOu5eZYCXTRUMP1DMT6KhbVCuH3G-f1KSyL5_L2iw@mail.gmail.com>
Thanks! Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20241 to track getting this spec'ed. Cheers, -- Ehsan <http://ehsanakhgari.org/> On Mon, Dec 3, 2012 at 7:04 PM, Chris Rogers <crogers@google.com> wrote: > > > On Mon, Dec 3, 2012 at 3:17 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote: > >> The spec doesn't mention anything about whether the implementation is >> supposed to resample the source audio buffer to the sample rate of the >> audio context when decoding the audio. From examining the behavior of >> Chrome, I think the WebKit implementation does resample audio when >> decoding, and the AudioBuffer passed to the success callback contains the >> resampled data. I can see both use cases for doing the resampling and not >> doing that, but I think the most common use case (playing the AudioBuffer >> back later) requires us to resample. >> >> What do people think about this? No matter what we end up doing, we need >> to say explicitly what needs to happen in the spec. >> >> Thanks! >> > > Hi Ehsan, sorry the spec isn't clear about this. The intended behavior is > for the implementation to resample the decoded audio data to the > AudioContext sample-rate as part of the decodeAudioData() operation. This > is so that we don't have to resample the data at playback time, which can > get very expensive especially with several sources playing back at the same > time. Sample-rate converting up-front allows us to use higher-quality > sample-rate conversion algorithms, since it's easier to afford the > expensive algorithms. > > Chris > > >> -- >> Ehsan >> <http://ehsanakhgari.org/> >> >> >
Received on Wednesday, 5 December 2012 00:02:07 UTC