Clamp spurious delay values to zero in AudioRendererImpl::Render.

A recent try where we incorrectly set negative delay in
FakeAudioOutputStream revealed this. It's certainly possible that this
is happening in production with OS provided streams under odd
conditions, so clamp to zero in these cases.

R=tguilbert

Change-Id: I032bb721f339cdbe34ed513d3c40223aca66fb5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1899560
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#712766}

media/renderers/audio_renderer_impl.cc

@@ -19,6 +19,7 @@
 #include "base/power_monitor/power_monitor.h"
 #include "base/single_thread_task_runner.h"
 #include "base/time/default_tick_clock.h"
+#include "base/time/time.h"
 #include "base/trace_event/trace_event.h"
 #include "build/build_config.h"
 #include "media/audio/null_audio_sink.h"
@@ -969,6 +970,11 @@ int AudioRendererImpl::Render(base::TimeDelta delay,
            << " prior_frames_skipped:" << prior_frames_skipped
            << " frames_requested:" << frames_requested;
 
+  // Since this information is coming from the OS or potentially a fake stream,
+  // it may end up with spurious values.
+  if (delay < base::TimeDelta())
+    delay = base::TimeDelta();
+
   int frames_written = 0;
   {
     base::AutoLock auto_lock(lock_);