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

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


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

linux-perf

media.desktop - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/114c7eb6e40000

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

Enable audio service sandbox feature on Linux test bots. by marinaciocea@chromium.org
https://chromium.googlesource.com/chromium/src/+/cde1131dcc8567362dc54cca802ca772ee380ed1
time_to_audio_play: 19.59 → 57.3 (+37.71)

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

Benchmark documentation link:
  None

I have not updates on this bug, please help reassign.

I think this is an issue with ALSA. I've managed to run the benchmark locally and there's only about 2 ms of difference with and without sandboxing while using pulseaudio. All around 25 ms.

When I run through ALSA, I get an average of a bit over double the time (around 110 ms vs around 50 ms) with sandboxing active in the field trials.

These values don't really match graphs, but the behavior does. We should probably look more into how the sandbox cooperates with ALSA.