Move bulk of media::AudioRendererImpl::Render() logic to media thread.

Move bulk of media::AudioRendererImpl::Render() logic to media thread.

r273571 moved running the time callback to the media thread. This change
moves even more, resulting in less locking throughout the class.

BUG=370634

[scherkus (not reviewing), 2014-07-10 17:10:40]

Here's the next one. I'm still doing performance testing as this CL always posts
a task whereas before we only posted if time changed.

The high level goal is to reduce the scope of locking so that only |algorithm_|
is the only thing locked for reading/writing. I also want to be able to query
timing information via |audio_clock_| on the media thread w/o having to grab the
lock for use with video frame scheduling.

[DaleCurtis, 2014-07-10 19:15:02]

Haven't reviewed yet, but I suspect this will impact the dropped frames count
for 2160p/4K video.  Will take a look shortly.

[DaleCurtis, 2014-07-10 23:37:00]

https://codereview.chromium.org/384543002/diff/20001/media/filters/audio_rend...
File media/filters/audio_renderer_impl.cc (right):

https://codereview.chromium.org/384543002/diff/20001/media/filters/audio_rend...
media/filters/audio_renderer_impl.cc:546: DVLOG(2) << __FUNCTION__;
Probably you should remove this, or make DVLOG(3). It's called roughly every
20ms or so these days.

https://codereview.chromium.org/384543002/diff/20001/media/filters/audio_rend...
media/filters/audio_renderer_impl.cc:575: DVLOG(2) << __FUNCTION__;
Ditto.

https://codereview.chromium.org/384543002/diff/20001/media/filters/audio_rend...
media/filters/audio_renderer_impl.cc:577: base::AutoLock auto_lock(lock_);
Only needed when accessing algorithm_ and reading?

https://codereview.chromium.org/384543002/diff/20001/media/filters/audio_rend...
File media/filters/audio_renderer_impl.h (right):

https://codereview.chromium.org/384543002/diff/20001/media/filters/audio_rend...
media/filters/audio_renderer_impl.h:167: void DidRender(RenderResult result);
const&

[DaleCurtis, 2014-07-10 23:37:37]

lgtm % nits.  Again, I'd monitor the dropped frame counts carefully.

[DaleCurtis, 2014-07-15 19:25:28]

(also comments from last PS seem unaddressed)

https://codereview.chromium.org/384543002/diff/40001/media/filters/audio_rend...
File media/filters/audio_renderer_impl.cc (right):

https://codereview.chromium.org/384543002/diff/40001/media/filters/audio_rend...
media/filters/audio_renderer_impl.cc:609:
audio_clock_->CurrentMediaTimestamp(base::TimeDelta()) ==
Shouldn't this be using the time since writing?

[scherkus (not reviewing), 2014-07-15 20:14:23]

Yeah I'm going to hold off landing this until I land some other CLs.

I'll likely get you to take another look before I CQ.

https://codereview.chromium.org/384543002/diff/40001/media/filters/audio_rend...
File media/filters/audio_renderer_impl.cc (right):

https://codereview.chromium.org/384543002/diff/40001/media/filters/audio_rend...
media/filters/audio_renderer_impl.cc:609:
audio_clock_->CurrentMediaTimestamp(base::TimeDelta()) ==
On 2014/07/15 19:25:28, DaleCurtis wrote:
> Shouldn't this be using the time since writing?

Maybe ... I'm still thinking what the right option is.

Using zero means we'll signal ended when there is no audio left in the hardware.

Using time_since_writing could make it so that we signal sooner than needed.


I suspect using time_since_writing should be fine, but I'll do some testing.

[DaleCurtis, 2014-07-15 20:16:20]

If using time since writing causes it to signal sooner than later, there may be
bugs in the latency information as constructed by AudioOutputResampler, etc, so
let me know if that's the case so I can hunt them down.