New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 735861 link

Starred by 1 user
Status: Assigned
Owner:
maxmorin@chromium.org
Cc:
cychiang@chromium.org
dalecur...@chromium.org
█ olka@chromium.org
hongchan@chromium.org
grunell@chromium.org
solenberg@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 734490


Sign in to add a comment

Uneven audio output device callbacks between browser and renderer threads

Project Member Reported by cychiang@chromium.org, Jun 22 2017 
This was found in https://bugs.chromium.org/p/chromium/issues/detail?id=734539#c15.

In https://bugs.chromium.org/p/chromium/issues/detail?id=710245, we disabled real-time priority on audio thread on renderer side.
The effort to re-enable RT priority is tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=734490

I tested on 2-core ChromeOS device gnawty on image R61-9674.0, Chrome version 61.0.3136.5, and found that there were uneven callbacks between browser and renderer, as shown in the attached screenshot.

Renderer being at priority 120 is not scheduled in one time interval, so it missed the request from browser.
This caused timeout on browser thread.

The step to reproduce:
1. Open page http://googlechrome.github.io/web-audio-samples/samples/audio/javascript-processing.html
2. In chrome://tracing, enable audio, renderer, webaudio, and then record the trace. (The webaudio check box will present if recording menu has once been opened while web audio is in use.)

Note that other webaudio test pages has serious issue.
It has more glitches and crash often.
E.g.:

http://googlechrome.github.io/web-audio-samples/samples/audio/box2d-js/box2d-audio.html
http://googlechrome.github.io/web-audio-samples/samples/audio/wavetable-synth.html
http://googlechrome.github.io/web-audio-samples/samples/audio/dj.html

So I recommend using http://googlechrome.github.io/web-audio-samples/samples/audio/javascript-processing.html to test.

The webaudio issue will be tracked in issue 734539.
trace_gnawty_R61_9674_js_processing.json.gz
778 KB Download
renderer_missed_fire_callback.png
350 KB View Download

Comment 1 by maxmorin@chromium.org, Jun 22 2017 

The glitches are sort of expected, considering that the IO thread has high priority on Chrome OS.

Re: "crash often", do you mean actual crashes? That seems like a pressing issue, could you file a separate bug for that (with crash ids)?

If we can ensure that the AudioDeviceThread doesn't take locks/allocate memory with PartitionAlloc, it might be ok to use realtime prio for WebAudio, even on two-core Chrome OS machines.

Comment 2 by cychiang@chromium.org, Jun 22 2017 

Sorry, it is not browser crash, but page crash with "Aw, Snap".
I have put the info in issue 734539 so hongchan@ can take a look.
Thanks!

Comment 3 by olka@chromium.org, Jun 22 2017 

Could we set CPU affinity somehow on ChromeOS to guarantee CPU time for threads with "normal" priority?

Comment 4 by yini...@chromium.org, Jun 29 2017

Status: Assigned (was: Untriaged)

Comment 5 by grunell@chromium.org, Jun 30 2017

Cc: grunell@chromium.org

Comment 6 by hongchan@chromium.org, Aug 14 2017

Cc: hongchan@chromium.org
maxmorin@

Thanks for looking into this. What are the options that we are looking at? I think having the elevated thread priority for WebAudio thread is beneficial for other regressions.
►

Sign in to add a comment