Implementation of 'AudioContext.getOutputTimestamp' method

content/renderer/media/renderer_webaudiodevice_impl.cc

Index: content/renderer/media/renderer_webaudiodevice_impl.cc
diff --git a/content/renderer/media/renderer_webaudiodevice_impl.cc b/content/renderer/media/renderer_webaudiodevice_impl.cc
index 4924cc68fc2afddce8aa90a0347f34edf74d9e89..46806cfd253286fb72781602fad523bd57a38ff2 100644
--- a/content/renderer/media/renderer_webaudiodevice_impl.cc
+++ b/content/renderer/media/renderer_webaudiodevice_impl.cc
@@ -110,11 +110,18 @@ int RendererWebAudioDeviceImpl::Render(base::TimeDelta delay,
   for (int i = 0; i < dest->channels(); ++i)
     web_audio_dest_data[i] = dest->channel(i);
 
+  // Substruct the bus duration to get hardware delay.
+  delay -= media::AudioTimestampHelper::FramesToTime(dest->frames(),

[miu, 2016/11/04 21:29:40]

Is this correct? I thought |delay| already did not include the samples in
|dest|.

If I'm mistaken: Is there a possibility of |delay| becoming negative here? Is
that acceptable in downstream code?

[Mikhail, 2016/11/07 18:28:03]

that comes from
https://codereview.chromium.org/2437863004/diff/200001/media/audio/audio_outp...
(line 313), so that repeated the behaviour existed before.
Therefore it should never become negative.

[miu, 2016/11/07 23:49:40]

Right, but isn't the output position correct without the subtraction here?
Meaning, WebAudio will render audio at the output position derived from |delay|
and |delay_timestamp|, and this will be the actual output position (or very
close to it) when the browser process *next* reads audio data from the sync
socket.

To elaborate further: There are 2 calls to AOC::OnMoreData() in the browser
process. The first one takes |delay| and increments it by one AudioBus' worth of
time, since it is the next OnMoreData() call that will be fetching the rendered
data. Let's call this estimated next |delay| value delay_next. In this method,
in the render process, the value for |delay| we have here is delay_next.
WebAudio will render as if the output position were at delay_next. Then, back in
the browser process when the *second* call to AOC::OnMoreData() is made, it's
|delay| argument should be equal (or very close) to delay_next, and that is the
correct value for the audio being fetched by sync_reader_->Read(dest) at that
time.

Does this make sense? Or, maybe I have got it wrong? ;)

[Mikhail, 2016/11/28 15:15:59]

You are right, this will be an estimation of the next buffer start position in
future, however 'context.getOutputPosition()' should return actual values from
the near past, in this case estimation is more accurate (as we can fully rely on
platform API returning same kind of data, i.e. IAudioClock::GetPosition from
WASAPI).

[miu, 2016/11/29 20:51:04]

Seems right. I went through and re-read the spec again and thought about how
this information would be used by the page's JS. I think I see where I was
getting confused here. Thanks for being patient with me. :)

+                                                     params_.sample_rate());
+
   // TODO(xians): Remove the following |web_audio_source_data| after
   // changing the blink interface.
   WebVector<float*> web_audio_source_data(static_cast<size_t>(0));
   client_callback_->render(web_audio_source_data, web_audio_dest_data,
-                           dest->frames());
+                           dest->frames(), delay.InSecondsF(),
+                           (delay_timestamp - base::TimeTicks()).InSecondsF(),
+                           prior_frames_skipped);
+
   return dest->frames();
 }