Avoid slow AudioParam automation path when possible

Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

A couple of nodes needed to be updated because they weren't ready to handle
switching from automation to non-automation.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html

Committed: https://crrev.com/3338dd16e602d195a40833200211ff55e15e1586
Cr-Commit-Position: refs/heads/master@{#402227}

[Raymond Toy, 2016-06-17 17:32:52]

Description was changed from

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
even is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

BUG=551484
TESTS=correctness covered by existing tests.
==========

to

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

biquad-automation.html modified to end automation before the end of rendering to
show that changing from automation path to fast path works.

BUG=551484
TESTS=biquad-automation.html
==========

[Raymond Toy, 2016-06-17 17:34:37]

Description was changed from

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

biquad-automation.html modified to end automation before the end of rendering to
show that changing from automation path to fast path works.

BUG=551484
TESTS=biquad-automation.html
==========

to

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html
==========

[Raymond Toy, 2016-06-17 18:37:07]

Description was changed from

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html
==========

to

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

A couple of nodes needed to be updated because they weren't ready to handle
switching from automation to non-automation.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html
==========

[Raymond Toy, 2016-06-17 20:52:56]

rtoy@chromium.org changed reviewers:
+ hongchan@chromium.org

[Raymond Toy, 2016-06-17 20:52:56]

PTAL

[hongchan, 2016-06-20 16:14:41]

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/webaudio/biquad-automation-expected.txt
(left):

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation-expected.txt:2:
CONSOLE WARNING: line 264: BiquadFilter.frequency.setValueAtTime value 10000
outside nominal range [0, 8000]; value will be clamped.
Just curious - where does this warning go?

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/webaudio/biquad-automation.html (right):

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation.html:132: var coefs =
generateFilterCoefficients(filterCreator, parameters, renderDuration / 2);
Why half?

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation.html:150: // Sweep the
frequency +/- 9*440 Hz from the center.  This should cause the output to low at
Now it's 5, not 9.

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation.html:284:
f.detune.linearRampToValueAtTime(parameters.detune[1], renderDuration / 2);
If all the renderDuration is divided by 2, can we just make it half?

[Raymond Toy, 2016-06-20 16:57:56]

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/webaudio/biquad-automation-expected.txt
(left):

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation-expected.txt:2:
CONSOLE WARNING: line 264: BiquadFilter.frequency.setValueAtTime value 10000
outside nominal range [0, 8000]; value will be clamped.
On 2016/06/20 16:14:40, hoch wrote:
> Just curious - where does this warning go?

I modified the test so that the ramps don't exceed the nominal range anymore.  I
think this was a mistake in the original test that we were exceeding the nominal
range.

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/webaudio/biquad-automation.html (right):

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation.html:132: var coefs =
generateFilterCoefficients(filterCreator, parameters, renderDuration / 2);
On 2016/06/20 16:14:40, hoch wrote:
> Why half?

Actually, any value less than renderDuration - 128 frames is probably ok.  To be
able to test that we remove the last event, the last event must end before the
end of rendering.  I chose half somewhat arbitrarily as something that ends long
before before rendering ends to give the algorithm a chance to remove old
events.

https://codereview.chromium.org/2033503004/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/webaudio/biquad-automation.html:150: // Sweep the
frequency +/- 9*440 Hz from the center.  This should cause the output to low at
On 2016/06/20 16:14:40, hoch wrote:
> Now it's 5, not 9.

Oops.  I'll fix the comment.  This change is to keep the osc frequency within
the nominal range.

[Raymond Toy, 2016-06-24 16:42:11]

Ping

[hongchan, 2016-06-24 17:31:34]

lgtm

[Raymond Toy, 2016-06-27 16:49:46]

The CQ bit was checked by rtoy@chromium.org

[commit-bot: I haz the power, 2016-06-27 16:50:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 18:09:49]

Description was changed from

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

A couple of nodes needed to be updated because they weren't ready to handle
switching from automation to non-automation.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html
==========

to

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

A couple of nodes needed to be updated because they weren't ready to handle
switching from automation to non-automation.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html
==========

[commit-bot: I haz the power, 2016-06-27 18:09:50]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-06-27 18:13:11]

Description was changed from

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

A couple of nodes needed to be updated because they weren't ready to handle
switching from automation to non-automation.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html
==========

to

==========
Avoid slow AudioParam automation path when possible

Currently, when any automation method is called for an AudioParam, all
future uses for the AudioParam must go through the timeline processing
code. This can be slow.

To optimize this, when running the timeline, check to see if the last
event is in the past (and is not a SetTarget event, which lasts
forever), and just quickly return the default value.  Also empty the
timeline since all events are past.  Then the faster non-timeline code
can be done.

A couple of nodes needed to be updated because they weren't ready to handle
switching from automation to non-automation.

biquad-automation.html modified to end automation before the end of rendering
to show that changing from automation path to fast path works.

audio-testing.js updated to handle a relative error of Infinity.  This
happens because the expected value is 0 so the relative error is either
Infinity or NaN.

BUG=551484
TESTS=biquad-automation.html

Committed: https://crrev.com/3338dd16e602d195a40833200211ff55e15e1586
Cr-Commit-Position: refs/heads/master@{#402227}
==========

[commit-bot: I haz the power, 2016-06-27 18:13:12]

Patchset 6 (id:??) landed as
https://crrev.com/3338dd16e602d195a40833200211ff55e15e1586
Cr-Commit-Position: refs/heads/master@{#402227}