All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=886974

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=b9f085db23bc1437c620cc67b2f74b67cab0ddef5b68ce4985a33e7603f25fb8


Bot(s) for this bug's original alert(s):

linux-perf
mac-10_13_laptop_high_end-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/133ab248e40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/133ab248e40000

Don't hold audio rendering lock while reading from demuxer. by dalecurtis@chromium.org
https://chromium.googlesource.com/chromium/src/+/fae6a1ad5b8311783f42221073e262b2897e8087
1.282e+04 → 1.079e+04 (-2022)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Huh, didn't expect this, but thinking about how the clockless tests work it's not surprising. Clockless playback is a repeated post task acquiring the lock as fast as possible, so yielding it here means we miss the opportunity to fulfill the read right away. In practice this shouldn't be an issue since real playback doesn't lock like that -- so WontFix.

 Issue 888065  has been merged into this issue.