- From: <bugzilla@jessica.w3.org>
- Date: Thu, 24 Jan 2013 05:55:06 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17424
Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jussi.kalliokoski@gmail.com
--- Comment #1 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
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?
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 24 January 2013 05:55:08 UTC