Fix latency plumbing in media::VirtualAudio[Input|Output]Stream.

Fix latency plumbing in media::VirtualAudio[Input|Output]Stream.

Adds accounting for the buffer offsets introduced by the graph of
media::AudioConverters.  Also, fixed the latency value being emitted by
VirtualAudioInputStream (should be zero, not the audio_bus duration).

This change, in combination with
https://codereview.chromium.org/759383003, results in
CastV2PerfomanceTest's av_sync metric becoming 0.359 ms (down from
24.7 ms).

Committed: https://crrev.com/06e0b571a9cbb948564ea986f3dea0b9d8c87492
Cr-Commit-Position: refs/heads/master@{#306302}

[miu, 2014-11-27 02:15:32]

miu@chromium.org changed reviewers:
+ hubbe@chromium.org

[miu, 2014-11-27 02:15:33]

hubbe: More awesome to improve AV sync.  PTAL.

[hubbe, 2014-12-01 21:56:46]

LGTM

Unfortunately I'm not very familiar with the frameworks, so depending on your
comfort level, another review may be appropriate.

https://codereview.chromium.org/756733003/diff/1/media/audio/virtual_audio_ou...
File media/audio/virtual_audio_output_stream.cc (right):

https://codereview.chromium.org/756733003/diff/1/media/audio/virtual_audio_ou...
media/audio/virtual_audio_output_stream.cc:85: audio_bus,
static_cast<uint32>(upstream_delay_in_bytes));
Is this allowed to not be a multiple of channels*bytes_per_sample?

[miu, 2014-12-02 00:00:50]

The CQ bit was checked by miu@chromium.org

[commit-bot: I haz the power, 2014-12-02 00:02:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/756733003/1

[miu, 2014-12-02 00:02:44]

https://codereview.chromium.org/756733003/diff/1/media/audio/virtual_audio_ou...
File media/audio/virtual_audio_output_stream.cc (right):

https://codereview.chromium.org/756733003/diff/1/media/audio/virtual_audio_ou...
media/audio/virtual_audio_output_stream.cc:85: audio_bus,
static_cast<uint32>(upstream_delay_in_bytes));
On 2014/12/01 21:56:46, hubbe wrote:
> Is this allowed to not be a multiple of channels*bytes_per_sample?

The call to GetBytesPerSecond() ensures this, since it will be a multiple of
that expression.

BTW--The "bytes delay" interface is poor (agreed by multiple owners), to be
replaced by a TimeDelta (probably).  There's a bug open for this.

[commit-bot: I haz the power, 2014-12-02 00:04:48]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-12-02 00:05:27]

Patchset 1 (id:??) landed as
https://crrev.com/06e0b571a9cbb948564ea986f3dea0b9d8c87492
Cr-Commit-Position: refs/heads/master@{#306302}