- From: Karl Tomlinson <karlt+public-audio@karlt.net>
- Date: Mon, 20 Jan 2014 20:42:16 +1300
- To: kg@luminance.org
- Cc: "public-audio\@w3.org" <public-audio@w3.org>
On Fri, 17 Jan 2014 20:41:48 -0800, K. Gadd wrote: > If buffers are resampled offline at load time, what does this > mean for the data observed by getChannelData? Is it the > resampled data? Yes. The AudioBuffer has the resampled data and sampleRate equal to the sampleRate of the AudioContext (consistent with the data). > Is the data un-resampled somehow to reproduce the original data > that was placed into the buffer, and is it resampled again when > you write to the buffer? No. > It seems as if getChannelData has to expose the actual, > resampled buffer. In this case, how is that resampling exposed? Yes. The AudioBuffer already represents the resampled data (and rate). > Will all AudioBuffer instances have a sampleRate property with a > value matching the sampleRate of the AudioContext? No. AudioBuffers from createBuffer can have a different sampleRate, and AudioBuffers from decodeAudioData on an OfflineAudioContext will have the (possibly different) sampleRate used to create the offline context. OfflineAudioContext provides a means for a client to decode to its chosen sample rate to save memory if desired. > P.S. the current spec version says this: > > sampleRate > > The sample rate (in sample-frames per second) at which the > AudioContext handles audio. It is assumed that all AudioNodes in > the context run at this rate. In making this assumption, > sample-rate converters or "varispeed" processors are not > supported in real-time processing. > > This seems to contradict AudioBufferSourceNode's support for sample-rate > conversion, unless something else is meant by that statement. There is a sample-rate converter in AudioBufferSourceNode, but the output of the node has the same sample rate as the AudioContext. I assume the AudioContext documentation (quoted above) is there to clarify that no nodes will have different input and output sample rates.
Received on Monday, 20 January 2014 07:43:05 UTC