Sort event list if any event time was clamped

Sort event list if any event time was clamped

Per spec, if an AudioParam event is scheduled in the past, the event
time is clamped to the current time.  However, this clamping can
change to time order of the event list so that it is no longer in
sorted order.

Thus, if any event has it's time clamped, the event list needs to be
sorted in time order again.  The sort must be stable to preserve the
behavior of events that were scheduled at the same time.

Some additional DCHECKs added to verify sorted order.

Unable to come up with a test for this using an offline context.
 
BUG=678802
TEST=Run test from bug report.

Review-Url: https://codereview.chromium.org/2623563002
Cr-Commit-Position: refs/heads/master@{#442382}
Committed: https://chromium.googlesource.com/chromium/src/+/2d2dfb10fa78a88b6ac615b8041948b13df181bb

[Raymond Toy, 2017-01-09 18:39:16]

Description was changed from

==========
Sort event list if any event time was clamped

Per spec, if an AudioParam event is scheduled in the past, the event
time is clamped to the current time.  However, this clamping can
change to time order of the event list so that it is no longer in
sorted order.

Thus, if any event has it's time clamped, the event list needs to be
sorted in time order again.  The sort must be stable to preserve the
behavior of events that were scheduled at the same time.

Some additional DCHECKs added to verify sorted order.

BUG=678802
TEST=
==========

to

==========
Sort event list if any event time was clamped

Per spec, if an AudioParam event is scheduled in the past, the event
time is clamped to the current time.  However, this clamping can
change to time order of the event list so that it is no longer in
sorted order.

Thus, if any event has it's time clamped, the event list needs to be
sorted in time order again.  The sort must be stable to preserve the
behavior of events that were scheduled at the same time.

Some additional DCHECKs added to verify sorted order.

Unable to come up with a test for this using an offline context.
 
BUG=678802
TEST=Run test from bug report.
==========

[Raymond Toy, 2017-01-09 18:39:39]

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

[Raymond Toy, 2017-01-09 18:39:39]

PTAL

[Raymond Toy, 2017-01-09 18:40:25]

The CQ bit was checked by rtoy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-09 18:40:54]

Dry run: 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, 2017-01-09 20:24:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-09 20:24:31]

Dry run: This issue passed the CQ dry run.

[hongchan, 2017-01-09 21:56:14]

lgtm, but would it be necessary to monitor the regression in case of an extreme
burst of AudioParam scheduling somehow?

[Raymond Toy, 2017-01-09 22:21:10]

On 2017/01/09 21:56:14, hongchan wrote:
> lgtm, but would it be necessary to monitor the regression in case of an
extreme
> burst of AudioParam scheduling somehow?

Yeah, I don't know how we can do this other than to wait for bug reports.  If I
could
come up with an offline test, we could test, but I can't.  Using suspend causes
all of
the automations to get updated together so that I can't seem to any automation
to be out of order.

[Raymond Toy, 2017-01-09 22:21:24]

The CQ bit was checked by rtoy@chromium.org

[commit-bot: I haz the power, 2017-01-09 22:22:21]

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, 2017-01-09 22:44:41]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1484000484490390, "parent_rev":
"44fa14be4e8b5005fac56ddb3180ed051ff22acd", "commit_rev":
"2d2dfb10fa78a88b6ac615b8041948b13df181bb"}

[commit-bot: I haz the power, 2017-01-09 22:45:09]

Description was changed from

==========
Sort event list if any event time was clamped

Per spec, if an AudioParam event is scheduled in the past, the event
time is clamped to the current time.  However, this clamping can
change to time order of the event list so that it is no longer in
sorted order.

Thus, if any event has it's time clamped, the event list needs to be
sorted in time order again.  The sort must be stable to preserve the
behavior of events that were scheduled at the same time.

Some additional DCHECKs added to verify sorted order.

Unable to come up with a test for this using an offline context.
 
BUG=678802
TEST=Run test from bug report.
==========

to

==========
Sort event list if any event time was clamped

Per spec, if an AudioParam event is scheduled in the past, the event
time is clamped to the current time.  However, this clamping can
change to time order of the event list so that it is no longer in
sorted order.

Thus, if any event has it's time clamped, the event list needs to be
sorted in time order again.  The sort must be stable to preserve the
behavior of events that were scheduled at the same time.

Some additional DCHECKs added to verify sorted order.

Unable to come up with a test for this using an offline context.
 
BUG=678802
TEST=Run test from bug report.

Review-Url: https://codereview.chromium.org/2623563002
Cr-Commit-Position: refs/heads/master@{#442382}
Committed:
https://chromium.googlesource.com/chromium/src/+/2d2dfb10fa78a88b6ac615b80419...
==========

[commit-bot: I haz the power, 2017-01-09 22:45:10]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/2d2dfb10fa78a88b6ac615b80419...