Make more media APIs aware of |delay| and |delay_timestamp|

content/renderer/media/track_audio_renderer.cc

Index: content/renderer/media/track_audio_renderer.cc
diff --git a/content/renderer/media/track_audio_renderer.cc b/content/renderer/media/track_audio_renderer.cc
index a17f85c3a20846673b1f345fe7e6792e2c60bf1a..2e6b0cbe9a0484e8c81c26a59d7eb1128d26df39 100644
--- a/content/renderer/media/track_audio_renderer.cc
+++ b/content/renderer/media/track_audio_renderer.cc
@@ -39,9 +39,10 @@ base::TimeDelta ComputeTotalElapsedRenderTime(
 }  // namespace
 
 // media::AudioRendererSink::RenderCallback implementation
-int TrackAudioRenderer::Render(media::AudioBus* audio_bus,
-                               uint32_t frames_delayed,
-                               uint32_t frames_skipped) {
+int TrackAudioRenderer::Render(base::TimeDelta delay,
+                               base::TimeTicks delay_timestamp,
+                               int prior_frames_skipped,
+                               media::AudioBus* audio_bus) {
   TRACE_EVENT0("audio", "TrackAudioRenderer::Render");
   base::AutoLock auto_lock(thread_lock_);
 
@@ -50,19 +51,13 @@ int TrackAudioRenderer::Render(media::AudioBus* audio_bus,
     return 0;
   }
 
-  // Source sample rate equals to output one, see MaybeStartSink(), so using it.
-  uint32_t audio_delay_milliseconds = static_cast<double>(frames_delayed) *
-                                      base::Time::kMillisecondsPerSecond /
-                                      source_params_.sample_rate();
 
   // TODO(miu): Plumbing is needed to determine the actual playout timestamp
   // of the audio, instead of just snapshotting TimeTicks::Now(), for proper
   // audio/video sync.  http://crbug.com/335335
-  const base::TimeTicks playout_time =
-      base::TimeTicks::Now() +
-      base::TimeDelta::FromMilliseconds(audio_delay_milliseconds);
+  const base::TimeTicks playout_time = base::TimeTicks::Now() + delay;
   DVLOG(2) << "Pulling audio out of shifter to be played "

[miu, 2016/10/31 20:59:04]

In the bots' logs, I see this is what's being repeated a lot:

  [924:5672:1027/051440:ERROR:track_audio_renderer.cc(59)] Pulling audio out of
shifter to be played 0 ms from now. 512

This was a problem with the bot configuration. DVLOG(2) *should* produce
excessive logging, by definition. So, there's nothing wrong with your change.
Actually, there are other problems with the bot configuration, like the use of
--gtest_also_run_disabled_tests (!); and so you can't even disable faulty
tests?!? (which is what I would recommend if the re-land bounces back out)

The strange thing is: As this is unconditional logging (both before and after
this CL), I don't see why your change should be blamed. Looking at recent builds
on the bots, I don't see this being logged at all. I wonder if something in your
change is allowing audio to flow through TrackAudioRenderer where there wasn't
any before? (Maybe your change even unintentionally fixed something that was
broken?)

Therefore, I think you should be fine to go ahead and re-land the change. If it
bounces out for the same reason (excessive logging), IMHO, you would be
justified in filing a P0 bug since the webrtc bots have been misconfigured to
the point of blocking the commit of valid changes to the tree.

-           << audio_delay_milliseconds << " ms from now.";
+           << delay.InMilliseconds() << " ms from now.";
   audio_shifter_->Pull(audio_bus, playout_time);
   num_samples_rendered_ += audio_bus->frames();
   return audio_bus->frames();