AudioListener: use AudioParam attributes if supported. #9845

Merged
merged 1 commit into from Nov 20, 2016

Projects

None yet

3 participants

@andreasplan8
Contributor
@mrdoob
Owner
mrdoob commented Oct 12, 2016

What audio glitches are those by the way?
Or is this a workaround for something they are planning to fix soon?
Seems strange that setPosition() and setOrientation() wouldn't already set the values at the current time...?

@andreasplan8
Contributor

Listen to this simple example in Chrome 53. I'm playing two loops and rotating the listener. (example is not using three).

using setPosition()
http://labs.plan8.se/panner_test/?audioparam=0

using audioParam attributes
http://labs.plan8.se/panner_test/?audioparam=1

using audioParam attributes and scheduling the values 0.01 seconds:
http://labs.plan8.se/panner_test/?audioparam=1&time=0.01

My guess is that this is a new implementation in Chrome and not a bug.
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zH8QYCU0Y2I/-ZvcW-4TBwAJ

@mrdoob
Owner
mrdoob commented Oct 15, 2016

Just pinged some guys at Chrome to double check this is not a regression.

@hoch
hoch commented Oct 17, 2016

First, we removed the 'dezippering' from the implementation per spec.
https://webaudio.github.io/web-audio-api/#audioparam-transitions

setPosition() had the internal smoothing (i.e. dezippering) to make the transition glitchless but it's removed. This explains the glitch in the first test case in the #9845 (comment).

Also the fix in PR might not be what you want here. As suggested in the spec above, you have to use AudioParam's setTargetAtTime() or linearRampToValueAtTime() to achieve the smooth position change.

Lastly, I think Chrome is the only browser implemented this so far, so the web app still needs to take care of other browsers.

@mrdoob
Owner
mrdoob commented Oct 17, 2016 edited

Also, as per the spec, seems like setPosition() and setOrientation() are being deprecated.

@andreasplan8
Contributor

Ok, thanks for the info!
Should I make a new PR using setTargetAtTime() or linearRampToValueAtTime() ?

@hoch
hoch commented Oct 17, 2016

My assumption is that updateMatrixWorld() gets called for every frame. (~16.7ms) Then using linearRampToValueAtTime(value, currentTime + 0.017) might be slightly better. This ensures your audio listener to transition from the state A to B over 17ms without any glitch.

Please do the experiment with various durations. I think it mainly depends on the scene or the application you're rendering.

Can updateMatrixWorld(optional transitionDuration) be an option here? Allowing developers to choose the responsiveness of transition would be nice as well.

@mrdoob
Owner
mrdoob commented Oct 17, 2016

My assumption is that updateMatrixWorld() gets called for every frame. (~16.7ms) Then using linearRampToValueAtTime(value, currentTime + 0.017) might be slightly better.

I don't think hard-coding ms values is a good idea. Specially now that we're starting to deal with VR systems that run at 90fps (0.011ms). I guess we should use the delta from the previous frame instead?

@hoch
hoch commented Oct 17, 2016

SGTM.

@mrdoob mrdoob merged commit bdd753e into mrdoob:dev Nov 20, 2016
@mrdoob
Owner
mrdoob commented Nov 20, 2016

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment