Intent to Implement and Ship: WebAudio PannerNode automation

[Raymond Toy]

This is an updated intent of the original SpatialPannerNode intent, which proposed a new SpatialPannerNode.  Based on discussions, the SpatialPannerNode features are moved to the existing PannerNode.

Contact emails

rt...@chromium.org, hong...@chromium.org

Spec

http://webaudio.github.io/web-audio-api/

http://webaudio.github.io/web-audio-api/#the-pannernode-interface

http://webaudio.github.io/web-audio-api/#AudioListener

Summary

Add automation methods to PannerNode to allow for smoother panning effects.

Motivation

In the current PannerNode, the position and orientation of the source (along with the position, forward, and up vectors of the AudioListener) are set using methods from the main thread. This doesn't allow for sample accurate timing of the changes. In addition, it is up to the developer to update these parameters often enough to produce a smooth effect.

To solve this issue, the individual 3D components of the position and orientation of the source (and the position, forward, and up vectors of the listener) are made available as AudioParams. This allows the developer to automate the motion of the source through space in a smooth fashion. These parameters are a-rate; that is, the values are updated every sample frame instead of update once per rendering quantum (128 frames).

The initial discussion for the need for a new panner node is WebAudio issue 368 and issue 372. The final conclusion is in issue 749

Interoperability and Compatibility Risk

As an official part of the spec, we believe all browsers will implement this. The change is backward compatible with existing uses of the PannerNode. The spec currently lists the existing methods (setPosition, and setOrientation) as deprecated because their effect can be easily achieved by setting the individual components of the corresponding vectors. We do not intend, here, to remove these methods. We will mark them as deprecated and add counters so we can monitor their usage.

Ongoing technical constraints

The PannerNode supports two panning types: "equalpower" and "HRTF". We will implement the methods appropriately for "equalpower". Due to the complexity of HRTF, we will not add a-rate support for the HRTF panner at this time, preferring to keep the existing k-rate (128 frame) update rate. We feel that the inherent smoothing in the HRTF panner will smooth out the changes and is not worth the approximate 20x increase in complexity.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/590000

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5677186052784128

Requesting approval to ship?

Yes.

[Philip Jägenstedt]

LGTM1 to ship the new AudioParam attributes on PannerNode. The changes to AudioListener are very similar, would it make sense to ship that at the same time?

The spec says that the setPosition and setOrientation methods are deprecated, but these currently don't have use counters in Blink. Before the usage is known I don't think it would be a good idea to deprecate them. In terms of implementation complexity it seems harmless to keep them forever, but it would be nice to inform authors that the AudioParam attributes now exist, so a console message to that effect might be nice.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Raymond Toy]

Oh, yes, AudioListener would be changed at the same time since they work together to give you the spatialization effect.  We're going to add use counters for them so we can keep track. I was also going to add a deprecation message to notify the user.  Are you saying we should just give a console warning without saying they're deprecated?

[Rick Byers]

LGTM2 to ship

In general we don't add deprecation warnings until we have some evidence that API usage is rare enough to make removal likely to avoid console spam and conditioning developers to ignore such warnings (and avoid ourselves falling into the trap of unrealistic hope for removal).  These tokens are pretty generic, but maybe there's still some hope for some sort of quick httparchive search?  If that suggests that usage is quite small (eg. <100 sites from the top 500k), I'd be fine with immediate deprecation without bothering with a proactive UMA counter.   Alternately just add the UseCounter now and wait until there's some data to do an "intent to deprecate and remove" and generate the console warning.

[Dimitri Glazkov]

LGTM3.

:DG<

[Raymond Toy]

On Wed, Apr 20, 2016 at 11:06 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM2 to ship

In general we don't add deprecation warnings until we have some evidence that API usage is rare enough to make removal likely to avoid console spam and conditioning developers to ignore such warnings (and avoid ourselves falling into the trap of unrealistic hope for removal).  These tokens are pretty generic, but maybe there's still some hope for some sort of quick httparchive search?  If that suggests that usage is quite small (eg. <100 sites from the top 500k), I'd be fine with immediate deprecation without bothering with a proactive UMA counter.   Alternately just add the UseCounter now and wait until there's some data to do an "intent to deprecate and remove" and generate the console warning.

I'll just add a UseCounter for now.  And file a bug to remind me to check after a few releases to decide what to do about deprecation.

However, I'm guessing setPosition and setOrientation are currently fairly high for the panner.  If you don't move or turn, the panner is just an expensive way to do a fixed gain. :-)