Speed: Real-time audio threads in the browser process do not get CPU cycles |
||||||||
Issue descriptionMac OS X 10.11.6 Chrome/64.0.3282.167 Macbook Air Running AppRTC; browser-side has 1 input audio thread (117603) and 1 output audio thread (124631) which are expected to be real-time. Both threads show a pattern of intervals (up to ~18 ms long) where they do not get CPU cycles - see an example in the attachment. AUAudioInputStream::OnDataIsAvailable Wall: avg 0.264 ms count 4,701 max 19.268 ms ********** min 0.074 ms std 1.231 ms CPU: avg 0.165 ms count 4,701 max 2.445 ms min 0.073 ms std 0.125 ms AUHALStream::Render Wall: avg 0.199 ms count 9,479 max 19.098 ms **** min 0.005 ms std 0.848 ms CPU: avg 0.150 ms count 9,479 max 2.248 ms min 0.005 ms std 0.131 ms
,
Feb 26 2018
Don't see any blocking operations there except one-time memory allocation [1] and allocation at [2] which is not expected to happen under these circumstances, and is not expected to happen that often. [1] https://cs.chromium.org/chromium/src/media/audio/mac/audio_auhal_mac.cc?type=cs&q=AUHALStream::Render&sq=package:chromium&l=307 [2]https://cs.chromium.org/chromium/src/media/audio/mac/audio_low_latency_input_mac.cc?type=cs&q=AUAudioInputStream::OnDataIsAvailable&sq=package:chromium&l=731
,
Feb 26 2018
Could the Speed team take a look?
,
Feb 26 2018
Trace shows the time being spend between beginning of OnMoreData (https://cs.chromium.org/chromium/src/media/audio/audio_output_controller.cc?type=cs&q=AudioOutputController::OnMoreData&sq=package:chromium&l=366) and beginning of AudioSyncReader::WaitUntilDataIsReady. The only stuff in between is a couple of atomic ops. :/
,
Feb 28 2018
Hmm looks like the trace itself got dropped from the description. Reattaching.
,
Feb 28 2018
Did not work. Reattaching again.
,
Mar 1 2018
Related to Issue 811525 ?
,
Mar 6 2018
Maybe App Nap issue? vasanthakumar@ - is it possible that chrome was not in foreground during the test?
,
Mar 6 2018
@Olga: I dont think thats possible. I remember leaving it in the foreground while performing the test. Also at that moment all other tabs were closed. Only relevant ones to the test were active during that time. (~2 tabs)
,
Mar 8 2018
On Windows I would investigate an issue like this by recording an ETW trace, which would show me all context switch data, meaning it would show me exactly where the audio thread was waiting, and who woke it up, regardless of whether the delays were caused by Chrome, other software, or hardware. I've never used Instruments on OSX but my understanding is that it records the same types of information and allows the same type of analysis. Can the original reporter record this type of data and see if it reveals anything useful? Ideally this should let us jump from guesses to an observable explanation. I've heard that Instruments is easier to use than ETW, which wouldn't take much.
,
Jul 19
,
Aug 3
Dropping to p2 since it hasn't been worked on for sometime.
,
Sep 3
Issue 798690 has been merged into this issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by maxmorin@chromium.org
, Feb 26 2018