+xhwang since might be eme related.

xhwang: I noticed in the trace that we're calling ContentDecryptorDelegate::MakeMediaBufferResource on the render thread. So maybe that's what's holding up audio decoding if the render thread is blocked for a while?

Ok, I'm pretty convinced now that it's because we call PpapiDecryptor::Decrypt() on the render thread. So if the render thread blocks (in this case on a 500ms wall time task "ScheduledActionSendBeginMainFrame") decoding gets stalled.

Can we move PpapiDecryptor off the render thread?

ContentDecryptorDelegate::MakeMediaBufferResource should be pretty fast IIRIC. But you are right that decrypting using the CDM relies on the render main thread, and if the render main thread is blocked for a while it could trigger decode underflow. It's also possible that expensive JS operations (e.g. GC) could also block the render main thread.

Could you please add log/trace around DDS::Read() to see whether you see significant delay there?

https://cs.chromium.org/chromium/src/media/filters/decrypting_demuxer_stream.cc?rcl=4540741c764a85583b0ea02a1d533f43c70afedd&l=78

Sorry I missed #3.

As long as we use PPAPI, the operations must happen on the render thread. The plan is to switch to use mojo CDM (project SoDo) such that we can call Decrypt() directly on the media thread.

That's unfortunate. And there's no opportunity to make PpapiDecryptor multi-threaded so we can just call Decrypt on the media thread? I assume not.

In that case the only choice we have is to increase our decoded audio buffer length to reduce the chance of this occurring. And try to fix whatever is blocking the renderer main thread so long.

sunnyps: I recall you looking into a hang issue around BeginFrame? Is this the same thing? ScheduledActionSendBeginMainFrame() blocking for 500ms when switching to the tab?

Can't say for sure. We're still investigating the BeginMainFrame hang. The latest theory is that begin frames and swap acks stop arriving from the browser process when the hang happens. See https://groups.google.com/a/chromium.org/forum/#!topic/scheduler-dev/MOlpJJbr7B4 for more details. Being stuck in BeginMainFrame for 500 ms indicates we're either blocked waiting for the browser process or rasterizing the previous frame is taking absurdly long.

> And there's no opportunity to make PpapiDecryptor multi-threaded so we can just call Decrypt on the media thread? I assume not.

Last time I talked this is not entirely impossible. But given the fact PPAPI is going away and nobody is working on it, and we are switching to mojo CDM anyways, I think we should just wait for project SoDo to land, hopefully not too long.

Ok, sounds good.

Actually, this is too bad to not fix IMO. I'm going to increase the audio buffer capacity for encrypted streams temporarily until SoDo lands.

sgtm, thanks for working on this!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39

commit a51ee9488f2b82b1dc8e9c79881b97dc318f0b39
Author: watk <watk@chromium.org>
Date: Sat May 13 01:08:32 2017

media: Increase the default audio buffer size for encrypted streams

Encrypted audio may need to be decrypted on the renderer main thread
which means that long running tasks on that thread can stall audio
decoding, causing noticeable audio gaps.

By increasing the default initial buffer size from 200ms to 500ms for
encrypted streams, we should drastically reduce the occurrence of
audio hitches caused by this.

There is ongoing work to move decryption to the media thread, at which
point we can revert this change (http://crbug.com/403462).

This change has an impact on preload time (load() to loaded) for audio
because we now decode more. On a linux z620 preload time for crowd.ogg
goes from 94ms to 130ms. (Release, component, dcheck_always_on build).

BUG= 718161 

Review-Url: https://codereview.chromium.org/2858393002
Cr-Commit-Position: refs/heads/master@{#471522}

[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/chromecast/media/cma/backend/alsa/audio_decoder_alsa.cc
[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/media/cast/test/fake_media_source.cc
[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/media/filters/audio_renderer_algorithm.cc
[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/media/filters/audio_renderer_algorithm.h
[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/media/filters/audio_renderer_algorithm_unittest.cc
[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/media/renderers/audio_renderer_impl.cc
[modify] https://crrev.com/a51ee9488f2b82b1dc8e9c79881b97dc318f0b39/media/renderers/audio_renderer_impl.h

May want to give Netflix, Play Movies a heads up in case they notice any load time increases.

hbengali@: Can you help me with #13 please?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/251e255f303f954692cd7e2134ea54b37a9774ff

commit 251e255f303f954692cd7e2134ea54b37a9774ff
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Wed Mar 07 21:24:51 2018

media: Decrease the default audio buffer size for encrypted streams

This partially reverts https://codereview.chromium.org/2858393002/

Now mojo CDM is enabled by default, there's no contention on the main
render thread any more. Change the audio buffer size back to the
original value.

Note that it's still possible that audio performance is not as good as
clear audio due to extra decryption overhead. So still keep a separate
kStartingCapacityForEncryptedInMs constant to keep the ability to choose
a different capacity for encrypted audio. Will watch our metrics to see
whether we need more adjustment on this value.

Bug:  718161 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I7420950d05e35892d1ef595a77ee716f8a716d2f
Reviewed-on: https://chromium-review.googlesource.com/946864
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541584}
[modify] https://crrev.com/251e255f303f954692cd7e2134ea54b37a9774ff/media/filters/audio_renderer_algorithm.cc

FYI: I am not seeing significant change on eme-audio MTBR on canary channel. So the change sgtm so far. Will check the data again later.

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=2ba83fdd0f076ebabd0cacceb1529ee0

The NextAction date has arrived: 2018-04-09

Still no significant change over the metrics (see #17). Assuming we are okay here.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e72bb599577ae34097d6df704a1b72a6c87524cb

commit e72bb599577ae34097d6df704a1b72a6c87524cb
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Tue Oct 23 23:10:10 2018

media: Increase the default audio buffer size for encrypted streams

This partially reverts commit 251e255f303f954692cd7e2134ea54b37a9774ff.

After mojo CDM was enabled by default, with the performance gain, we
changed the audio buffer size back to the original value at 200ms,
which is the same as the size as clear playback.

Recently, we found cases where we still have performance issues for
encrypted audio. Given the fact that users are super sensitive to audio
glitches, and encrypted playback always has worse performance than clear
playback, it makes sense to use a larger buffer size.

This CL changes the audio buffer size back to 500ms. It may increase
the start-to-play time slightly, but should help reduce rebuffers during
playback.

Bug:  718161 ,879970
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I41909d3fc3356df119b21fe720ebe8cafad206a5
Reviewed-on: https://chromium-review.googlesource.com/c/1297329
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602165}
[modify] https://crrev.com/e72bb599577ae34097d6df704a1b72a6c87524cb/media/filters/audio_renderer_algorithm.cc