This is a bit trickier, since we need to figure out a way to have it run a `MediaStream` underneath, probably in a lazy fashion because a lot of applications don't even touch the listener or instantiate a `PannerNode`.

One way of doing this is to create AudioParams on the PannerNode corresponding to the new listener AudioParams, and create a "ListenerNode" associated with the listener AudioParams which can be connected to the corresponding AudioParams on the PannerNode. This isn't very efficient in the case where the listener AudioParams have simple values, which is probably most of the time. The other thing I've looked at a bit is to make it possible for an AudioParam to send events to multiple streams. The problem there is that events would be missed if the PannerNode is created after the listener is modified. I guess we could keep a backlog of events to work around that, but it sounds increasingly hacky. Paul, Karl, any better ideas? Thanks!

I expect it is possible to just have the single AudioParam for each of the AudioListener attributes, with the PannerNodeEngines reading directly from these. Listener streams (if they are required) would need to be connected to Panner streams just to ensure correct ordering of processing. Connections can be made when listener and panner streams are created. I don't think I'd create a ListenerNode as an AudioNode because these are dom objects, which are not required here. An object (usually an engine) needs to own AudioParamTimelines on the graph thread, and receive updates from a stream. I think (Offline)DestinationNodeEngine is the logical existing candidate here. There is no need to create another stream just for passing timeline events. The listener and destination are singletons wrt each AudioContext and the DestinationNodeEngine is the graph thread object corresponding to the AudioContext. Might need to s/DestinationNodeEngine/RealtimeDestinationNodeEngine/ and put the timelines on a base class for offline contexts also. What is missing is a way for AudioParam to know whether to connect streams it creates to a single downstream node or to all panner nodes. Perhaps a ListenerAudioParam class is an option, but that may be unnecessarily boilerplate for a just a difference in connecting streams. Can special values for the AudioParam aIndex and/or aNode be detected by AudioParam so as to connect appropriately? The AudioDestinationNode would be the appropriate aNode.

(In reply to Karl Tomlinson (:karlt) from comment #2) > Can special values for the AudioParam aIndex and/or aNode be detected > by AudioParam so as to connect appropriately? Perhaps better I guess to add a virtual method on AudioNode to connect the stream as appropriate. AudioDestinationNode would override this method. (If AudioDestinationNode has other AudioParams then aIndex could be passed to distinguish, but I guess that would be unused right now and so unnecessary.)

I agree with Karl here, sorry for the delay.

Mass change P2->P3 to align with new Mozilla triage process.