Re: About AudioPannerNode

Den 2012-06-20 23:37:12 skrev Chris Rogers <crogers@google.com>:

> On Wed, Jun 20, 2012 at 2:40 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> Just realized one more thing:
>>
>> How is the doppler effect supposed to work? I see that there is a  
>> section
>> in the spec for that too [1], but it obviously needs more detail.
>>
>> I guess that it would be implemented using some sort of FFT-based
>> pitch-shift algorithm (?).
>>
>
> Hi Marcus, I'll definitely need to add the detail in there.  The approach
> I've taken so far isn't nearly as complicated as implementing a
> pitch-shifting algorithm (which is hard to do well, has artifacts, and
> incurs latency).  Instead, the AudioPannerNode simply keeps track of all
> "up-stream" AudioBufferSourceNodes connected to it, and modifies the
> internal playback rate according to the pitch-shift calculated for the
> Doppler-shift.  Presumably this should also apply to Oscillator too.
>  Unfortunately, this approach may not work so well for other source nodes
> such as MediaElementAudioSourceNode.  I'm happy to simply spec that it  
> only
> works with AudioBufferSourceNode (and Oscillator) which I think will  
> cover
> the main use cases for games.  I'd be glad to hear your thoughts...
>

Hmmm... I agree that pitch-shift is difficult, and it would be nice to  
avoid it. Your approach seems logical. How about more complex graphs, e.g.  
including delays, filters and loops?

How about dynamically altering the sample rate of all nodes prior to the  
panner node instead, and apply re-sampling at the panner node input? That  
would be more correct w.r.t. filter nodes, for instance. That would also  
remove the need to implicitly track the source nodes from the panner  
nodes, and should probably also work for MediaElementAudioSourceNode (if  
you re-sample it according to the altered sample rate), as well as  
JavaScriptAudioNode source nodes.

It would on the other hand be tricky to handle processing-buffer  
alignment, perhaps requiring the addition of a slight latency to allow  
up-stream nodes to continue using 128-sample blocks. It would also require  
all nodes to support dynamic sample rate changes (if that is not already a  
requirement).

/Marcus


-- 
Marcus Geelnard
Core Graphics Developer
Opera Software ASA

Received on Thursday, 21 June 2012 07:33:21 UTC