Revert of Use double microseconds for tracking back/front timestamp in AudioClock.

Revert of Use double microseconds for tracking back/front timestamp in AudioClock. (patchset #3 id:40001 of https://codereview.chromium.org/1711473002/ )

Reason for revert:
Speculative revert: appears to break blink layout test webaudio/periodicwave-normalization.html on Linux Debug.
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20(dbg)/builds/6191

Original issue's description:
> Use double microseconds for tracking back/front timestamp in AudioClock.
> 
> Back timestamp is computed by summing the new frames_written for every
> call to WroteAudio. The number of microseconds per frame is often not
> a whole number (e.g. 20.833 mu for sample rate of 48Khz). Prior to this
> change, using TimeDelta to do the summing of frames_written meant we
> truncated to the nearest microsecond with every call to WroteAudio. The
> truncation error slowly accumulates in the back timestamp. After 2
> hours of playback this error causes noticeable audio/video sync drift.
> 
> Having front_timestamp be a double is less critical. Front timestamp
> is computed using back_timestamp at every call to WroteAudio, so fixing
> back implicitly fixes front. Still, I've changed them both to double
> for the sake of consistency and a slight improvement in accuracy.
> 
> BUG=564604
> 
> Committed: https://crrev.com/2ed08018de0593b905c18500c1784464dcbe5468
> Cr-Commit-Position: refs/heads/master@{#376287}

TBR=dalecurtis@chromium.org,chcunningham@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=564604

[Kunihiko Sakamoto, 2016-02-19 06:54:23]

Created Revert of Use double microseconds for tracking back/front timestamp in
AudioClock.

[Kunihiko Sakamoto, 2016-02-19 06:56:01]

Let me see if this fixes the test on trybot.

[Kunihiko Sakamoto, 2016-02-19 06:56:25]

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

[commit-bot: I haz the power, 2016-02-19 06:57:21]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1716753002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1716753002/1

[commit-bot: I haz the power, 2016-02-19 06:58:16]

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

[commit-bot: I haz the power, 2016-02-19 06:58:17]

Dry run: This issue passed the CQ dry run.

[Kunihiko Sakamoto, 2016-02-19 10:46:51]

On 2016/02/19 06:56:01, Kunihiko Sakamoto wrote:
> Let me see if this fixes the test on trybot.

Reverting this didn't fix the test on trybot.
Closing, sorry for the hassle.

[Kunihiko Sakamoto, 2016-02-19 10:47:04]

Description was changed from

==========
Revert of Use double microseconds for tracking back/front timestamp in
AudioClock. (patchset #3 id:40001 of https://codereview.chromium.org/1711473002/
)

Reason for revert:
Speculative revert: appears to break blink layout test
webaudio/periodicwave-normalization.html on Linux Debug.
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20(dbg)/...

Original issue's description:
> Use double microseconds for tracking back/front timestamp in AudioClock.
> 
> Back timestamp is computed by summing the new frames_written for every
> call to WroteAudio. The number of microseconds per frame is often not
> a whole number (e.g. 20.833 mu for sample rate of 48Khz). Prior to this
> change, using TimeDelta to do the summing of frames_written meant we
> truncated to the nearest microsecond with every call to WroteAudio. The
> truncation error slowly accumulates in the back timestamp. After 2
> hours of playback this error causes noticeable audio/video sync drift.
> 
> Having front_timestamp be a double is less critical. Front timestamp
> is computed using back_timestamp at every call to WroteAudio, so fixing
> back implicitly fixes front. Still, I've changed them both to double
> for the sake of consistency and a slight improvement in accuracy.
> 
> BUG=564604
> 
> Committed: https://crrev.com/2ed08018de0593b905c18500c1784464dcbe5468
> Cr-Commit-Position: refs/heads/master@{#376287}

TBR=dalecurtis@chromium.org,chcunningham@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=564604
==========

to

==========
Revert of Use double microseconds for tracking back/front timestamp in
AudioClock. (patchset #3 id:40001 of https://codereview.chromium.org/1711473002/
)

Reason for revert:
Speculative revert: appears to break blink layout test
webaudio/periodicwave-normalization.html on Linux Debug.
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20(dbg)/...

Original issue's description:
> Use double microseconds for tracking back/front timestamp in AudioClock.
> 
> Back timestamp is computed by summing the new frames_written for every
> call to WroteAudio. The number of microseconds per frame is often not
> a whole number (e.g. 20.833 mu for sample rate of 48Khz). Prior to this
> change, using TimeDelta to do the summing of frames_written meant we
> truncated to the nearest microsecond with every call to WroteAudio. The
> truncation error slowly accumulates in the back timestamp. After 2
> hours of playback this error causes noticeable audio/video sync drift.
> 
> Having front_timestamp be a double is less critical. Front timestamp
> is computed using back_timestamp at every call to WroteAudio, so fixing
> back implicitly fixes front. Still, I've changed them both to double
> for the sake of consistency and a slight improvement in accuracy.
> 
> BUG=564604
> 
> Committed: https://crrev.com/2ed08018de0593b905c18500c1784464dcbe5468
> Cr-Commit-Position: refs/heads/master@{#376287}

TBR=dalecurtis@chromium.org,chcunningham@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=564604
==========