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

Re: [web-audio-api] Setting sample rates for individual JavaScriptProcessingNodes (#232)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:30:31 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/232/24244867@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17424#0) by Jussi Kalliokoski on W3C Bugzilla. Thu, 24 Jan 2013 05:55:06 GMT

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?

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:40:08 UTC

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