Motown: Delay audio track completion of Prime requests until a packet arrives.

services/media/audio/audio_pipe.cc

Index: services/media/audio/audio_pipe.cc
diff --git a/services/media/audio/audio_pipe.cc b/services/media/audio/audio_pipe.cc
index 66ae598186e341de769259f40c5c5618f7d25284..eba55cd3a2b7e30a1bd0721e09b3f81264bb2322 100644
--- a/services/media/audio/audio_pipe.cc
+++ b/services/media/audio/audio_pipe.cc
@@ -131,6 +131,22 @@ void AudioPipe::OnPacketReceived(MediaPacketStatePtr state) {
                            std::move(regions),
                            start_pts,
                            next_pts_)));
+
+   if (!prime_callback_.is_null()) {
+     // Prime was requested. Call the callback to indicate priming is complete.
+     // TODO(dalesat): Don't do this until low water mark is reached.

[kulakowski, 2016/03/28 20:46:12]

For my edification: What is priming? What is a "low water mark"?

[dalesat, 2016/03/28 22:19:56]

Priming is getting some initial packets of content in place so that renderers
don't starve when we 'play'. We want some content queued up so the renderer has
something to chew on right away.

The low water mark is the least amount of content we can have queued at the
renderer and still be confident that it won't starve due to whatever delays
happen elsewhere in the graph. Right now, we're not experiencing any starvation
when we have one packet ready...but that's presumably dependent on how much data
is in the packet and some other stuff.

The primary concern at the moment is that we want to see at least one packet so
we know what timestamp it has. When we start at the beginning of the file, the
timestamp will typically be 0. When we seek, the timestamp will be something
quite different. We need to know the timestamp, because we do rate control by
saying 'the packet with timestamp X needs to be presented at real time Y'.

[kulakowski, 2016/03/30 20:44:55]

Gotcha. Couple more questions.

How is seeking different from starting? You said "typically 0", which I guess
isn't a priori clear to me that it would always be the case. What are the
atypical cases?

How is an AudioPipe supposed to be able to calculate this amount of content, for
low water marking?

[dalesat, 2016/03/30 21:04:14]

Content is typically authored such that the first packets in each stream are
timestamped roughly 0. Some content could just be weird and start at some other
value. If we're hooking up to a live feed, the initial timestamp could be
anything.

When we seek, we pause playback, flush all the packets in the pipeline, tell the
demux (source of packets) to seek to a new position, and then prime. In that
case, the first packet to arrive at the audio track will have a timestamp that
roughly corresponds to our seek position (which can be zero).

Calculating the low water mark is mostly a matter of picking a number (probably
a time interval) that works (prevents underflow) consistently. A lot of factors
can affect how low this value can be, including stuff like scheduling latency.
In the end, we will probably come up with a hard-coded time interval that always
seems to work based on our testing. We might also let an application set this,
so it can balance risk of underflow vs latency.

[kulakowski, 2016/03/31 21:32:12]

It really does not seem to me that this is a single policy audio_pipe needs to
create. A single hardcoded interval doesn't seem like it will be correct for
everyone.

[dalesat, 2016/03/31 21:45:14]

Sure. Is this a concern for this CL?

[kulakowski, 2016/03/31 22:43:34]

Well if you have a TODO about it in the implementation of it, it seems to be to
me.

+     prime_callback_.Run();
+     prime_callback_.reset();
+   }
+}
+
+void AudioPipe::OnPrimeRequested(const PrimeCallback& cbk) {
+  if (!prime_callback_.is_null()) {
+    // Prime was already requested. Complete the old one and warn.
+    LOG(WARNING) << "multiple prime requests received";
+    prime_callback_.Run();
+  }
+  prime_callback_ = cbk;
 }
 
 bool AudioPipe::OnFlushRequested(const FlushCallback& cbk) {