This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Closed per http://www.w3.org/2011/audio/track/issues/4 Raised by Jussi as: “Ideally, the end developer should be able to create custom processing nodes with specific sample rates within a single AudioContext. This is very useful, since high quality resampling in JavaScript is relatively expensive, and a required feature for anything that deals with external media sources, for example JS codecs.The sample rate should also be possible to be changed on the fly to allow for features like changing the playback rate of a codec (required if you'd want to use JS codecs to extend <audio> for example).” Resolved on 2 Apr 2012 teleconference: http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0010.html Resolution: add a constructor parameter for audio context to specify sample rate - make sure to specify that default is best unless needed.
The thing is that the context already resamples other audio sources, such as the MediaElementAudioSource and MediaStreamAudioSource, it seems a bit silly that for example the JavaScript codecs we have can't take advantage of this resampling engine as well. After all, in this case, the ScriptProcessorNode is just another external audio source. I think there are two ways to fix this: * ScriptProcessorNodes should have a changeable sampleRate attribute. Without further changes, however, this leads to any nodes that are fed into the ScriptProcessorNode to have a changed sample rate, or that the ScriptProcessorNode would have to resample in-and-out. I think the most reasonable way to avoid these problems is to allow changing of sample rate only on ScriptProcessorNodes with 0 inputs (including AudioParams). I think it's fairly safe to assume that all external resources that are fed to the context through the ScriptProcessorNode don't have any inputs from the graph itself. * The other way is to have a ResamplerNode or similar. This would have applications beyond external audio resources as well, one could for example use such a node to achieve a surging slow-motion effect, such as Bullet Time in Max Payne or similar. However, this would immensely complicate the implementation of all nodes in the graph and make it a bit too easy to create mind-boggling processing graphs. E.g. what on earth happens when you put a ResamplerNode into the feedback loop of a delay?