[TO M49] Use double microseconds for tracking back/front timestamp in AudioClock.

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
Review URL: https://codereview.chromium.org/1711473002

Cr-Commit-Position: refs/heads/master@{#376287}
(cherry picked from commit 2ed08018de0593b905c18500c1784464dcbe5468)

Committed: https://chromium.googlesource.com/chromium/src/+/11f31429480770414493d53c38f9e929e10d688f

[chcunningham, 2016-02-25 00:04:04]

Description was changed from

==========
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

Review URL: https://codereview.chromium.org/1711473002

Cr-Commit-Position: refs/heads/master@{#376287}
(cherry picked from commit 2ed08018de0593b905c18500c1784464dcbe5468)
==========

to

==========
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

Review URL: https://codereview.chromium.org/1711473002

Cr-Commit-Position: refs/heads/master@{#376287}
(cherry picked from commit 2ed08018de0593b905c18500c1784464dcbe5468)

Committed:
https://chromium.googlesource.com/chromium/src/+/11f31429480770414493d53c38f9...
==========

[chcunningham, 2016-02-25 00:04:06]

Committed patchset #1 (id:1) manually as
11f31429480770414493d53c38f9e929e10d688f.

[chcunningham, 2016-02-25 00:05:06]

Description was changed from

==========
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

Review URL: https://codereview.chromium.org/1711473002

Cr-Commit-Position: refs/heads/master@{#376287}
(cherry picked from commit 2ed08018de0593b905c18500c1784464dcbe5468)

Committed:
https://chromium.googlesource.com/chromium/src/+/11f31429480770414493d53c38f9...
==========

to

==========
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

Review URL: https://codereview.chromium.org/1711473002

Cr-Commit-Position: refs/heads/master@{#376287}
(cherry picked from commit 2ed08018de0593b905c18500c1784464dcbe5468)

Committed:
https://chromium.googlesource.com/chromium/src/+/11f31429480770414493d53c38f9...
==========