Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to deprecate: doppler computation in the PannerNode/AudioListener

39 views
Skip to first unread message

Paul Adenot

unread,
Apr 14, 2015, 9:08:07 AM4/14/15
to dev-pl...@lists.mozilla.org
Continuing on the path to a less broken panning model on the Web Audio
API, this is a followup to [0]

The Web Audio API has a number of API that allow setting the velocity of
a "listener" and a "panner", along with the speed of sound, and a
"doppler factor", to be able to automatically pitch up or down connected
audio sources according to their speed.

This feature has a number of issues:
- It only pitches up or down AudioBufferSourceNodes (not other sources:
OscillatorNode, HTMLMediaElement, ScriptProcessorNode, AudioWorkerNode,
MediaStreams) connected to a PannerNode
- It's not clear what should happen if a single AudioBufferSourceNode is
connected to more than one PannerNode with different velocities, and the
right thing to do would depend on the use case
- By using methods (setVelocity(x, y, z), called on the main thread, at
requestAnimationFrame rate, for example), and not AudioParams (a Web
Audio API object that lets author schedule smooth transition at audio
rate on the audio thread, say 44100Hz), this mechanism was producing
noticeable glitches when relative velocity were high

For those reasons, the W3C Audio WG has agreed a while back to remove
those members entirely. Authors that need this feature can replicate the
effect in a much more generic and glitch-free way in their application.
I'm planning to do a writeup on how to do so on MDN.

This has been shipped in Gecko for some time, although I've been looking
at a large amount of code on GitHub (searching for the to be deprecated
members names and such), and it's not being used a lot, so I went ahead
and wrote two patch, one to remove the members, and one to warn authors
that those members are deprecated [1].

Blink currently marks those members as deprecated [2]. The plan is to
currently mark those as deprecated in Gecko as well, and then remove the
deprecated members from both implementations at roughly the same time
(Blink developers are targeting a version in 6 months). They will be
adding usage counters to watch the usage of those members in the wild.

Additionally, if someone has an idea on what to link to/what to say in
the actual deprecation notice, I'm all ears, the current message is more
or less a placeholder.

Thanks,
Paul.

[0]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/5pxl_Ht04sY
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1148354
[2]:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-1SI1GoHYO8

Ehsan Akhgari

unread,
Apr 14, 2015, 12:07:59 PM4/14/15
to Paul Adenot, dev-pl...@lists.mozilla.org
On 2015-04-14 9:07 AM, Paul Adenot wrote:
> Additionally, if someone has an idea on what to link to/what to say in
> the actual deprecation notice, I'm all ears, the current message is more
> or less a placeholder.

Perhaps we can document this in more detail on MDN and link to the docs
page?

0 new messages