About AudioPannerNode

Here's another subject... :)

I've looked a bit at the AudioPannerNode/AudioListenerNode pair, and I  
think there are a few things that need to be discussed.


First of all, the AudioPannerNode is a bit of a odd-one-out among the  
audio nodes, since it has an implicit dependency on the AudioListenerNode  
of the context to which the panner node belongs. If we wanted to decouple  
audio nodes from the audio context (e.g. to make it possible to connect  
nodes from different audio contexts, as have been suggested), the  
AudioPannerNode becomes a special case. Not sure how an alternate solution  
should be designed (discussions welcome), but one idea could be to  
decouple the AudioListenerNode from the AudioContext, and manually  
construct listener nodes and set the listener node for each panner node.  
This would also make it possible to have any number of listeners (e.g. for  
doing background sounds or other listener-aligned sound sources).

Btw, the current design also makes it difficult/impossible to implement  
the AudioPannerNode using a JavaScriptAudioNode.


Another thing is that I don't really see how a non-mono input signal would  
make sense for a panner node, at least not if we think of it as a 3D  
spatialization tool. For instance, in an HRTF model, I think an audio  
source should be in mono to make sense. Would it be a limitation if all  
inputs are down-mixed to mono?

On the other hand, in music applications you may want to do left-right  
panning of stereo signals. Should that be treated as a special case  
(configuration) of the AudioPannerNode, or would it be better to split the  
current interface into two (e.g. StereoPannerNode and SpatializationNode)?


Lastly, how should complex spatialization models (thinking about HRTF  
here) be handled (should they even be supported)? I fear that a fair  
amount of spec:ing and testing must be done to support this, not to  
mention that HRTF in general relies on data files from real-world  
measurements (should these be shared among implementations or not? should  
there be high/low-quality versions of the impulse responses? etc). Would  
it perhaps be a good idea to leave this for a later revision or another  
level of the spec?


Regards,

   Marcus

Received on Tuesday, 19 June 2012 09:50:34 UTC