AudioBufferSourceNode playbackRate rampToValueAtTime
Reported by
m...@noteflight.com,
Dec 9 2016
|
||||||
Issue descriptionChrome Version : 55.0.2883.75 (Official Build) (64-bit) URLs (if applicable) : https://jsfiddle.net/v22s9dda/21/ Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Chrome Canary 57: Fail Firefox 50: OK Changing the playbackRate of an AudioBufferSourceNode with rampToValue doesn't reach the target value in certain cases. See this jsfiddle demo for more details: https://jsfiddle.net/v22s9dda/21/ Here's an example of this causing a problem in the wild: https://www.noteflight.com/scores/view/3d3944c3fd22bb9fbd89ab3cbc5de65aa3ed47b6 Thanks for your time!
,
Dec 12 2016
,
Dec 12 2016
,
Dec 12 2016
This is a bug in how k-rate parameters are being handled when the end time of the event (which must be the last event) is before the current time. The returned value was set to the last computed value instead of using the end value of the event.
,
Dec 12 2016
,
Jan 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/01154e998c7a37c47cf83aabe44331ff4503ec3c commit 01154e998c7a37c47cf83aabe44331ff4503ec3c Author: rtoy <rtoy@chromium.org> Date: Wed Jan 18 20:13:44 2017 k-rate playbackRate and detune reaches final value The optimization for the case when the last event is in the past does not work for k-rate AudioParams because the final value returned is the last value requested. This happens because for k-rate parameters we only ask for one sample from the automation at the beginning of the rendering quantum. This also computes a default value for future use. At the next render, the event is in the past so we were just using the default value, which is actually now a render quantum behind. Change the criteria so that we wait for 1.5 render quantum before applying the optimization. This allows the timeline to compute one more value, updating the default value too, which will be the correct ending value of the event. Additional test added that illustrates the issue is fixed and also test for the other k-rate parameters. BUG= 672857 TEST=audioparam-k-rate.html Review-Url: https://codereview.chromium.org/2567183002 Cr-Commit-Position: refs/heads/master@{#444455} [add] https://crrev.com/01154e998c7a37c47cf83aabe44331ff4503ec3c/third_party/WebKit/LayoutTests/webaudio/AudioParam/audioparam-k-rate.html [modify] https://crrev.com/01154e998c7a37c47cf83aabe44331ff4503ec3c/third_party/WebKit/Source/modules/webaudio/AudioParamTimeline.cpp
,
Jan 20 2017
Tried the repro case with the fix. The printed output value reaches 0.5 consistently now. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by kkaluri@chromium.org
, Dec 12 2016