audio_sync_reader and audio_input_sync_writer WARNING floods output |
||||
Issue descriptionI've seen it on my Chromium local builds, e.g. [10138:149023:0713/135551:WARNING:audio_sync_reader.cc(132)] AudioSyncReader::Read timed out, audio glitch count=1 [10138:40963:0713/135552:WARNING:audio_input_sync_writer.cc(241)] AISW: No room in fifo. and in bots e.g. [1]. repeated a large amount of times, including on experiments not involving audio. Please consider refactoring to log fewer times or changing it to DVLOG(). [1] https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/56929/steps/browser_tests/logs/stdio/text
,
Jul 15 2016
In that log the audio_sync_reader messages are 2720 lines out of 23041 lines total, i.e. ~12%. I can see a few much worse offenders, e.g. ~10319 lines of 'Failed to reserve I420 output buffer' from video_capture_device_client.cc and 5366 lines of "Returning video-not-playing to test." from test_functions.js. Having said that, I'm actually surprised to see those audio glitch messages. IIUC those shouldn't typically happen in most cases. Is the audio writer thread blocked by something in the renderer process in those tests?
,
Jul 15 2016
#2: 'Failed to reserve I420 Output Buffer' was already cleaned up in https://codereview.chromium.org/2124073006/ (no bug, apparently). The Js verboseness is also quite annoying and should be addressed. About the root cause, I've seen it when I start using JS's PeerConnection, that IIUC runs in main thread, hiccuping everything that is supposed to run over there, could this be a reason?
,
Jul 15 2016
No, I believe audio IPC is using a separate thread (see https://cs.chromium.org/chromium/src/media/audio/audio_device_thread.h?rcl=1468596139&l=25). So even if the main thread is kept busy by PeerConnection or something else, there should be no audio hiccups, as long as the audio thread is not blocked (since it runs at high priority, https://cs.chromium.org/chromium/src/media/audio/audio_device_thread.cc?rcl=0&l=51). TBH I'm not super familiar with this stuff, so +dalecurtis@. I think logging glitches as warnings is good, since those typically indicate problems and should happen only very infrequently and we want them to be visible, to draw our attention to issues. But I'm not sure what could be causing audio glitches in this case.
,
Jul 17 2016
"AISW: No room in fifo" lines are capped to 50. Is that not sufficient?
,
Nov 14 2017
These lines are still covering the logs 3500+ times and causing it to fail with excessive log output. Can somebody take a look if we cna filter them? [12917:159499:1110/085429.891119:WARNING:audio_sync_reader.cc(189)] AudioSyncReader::Read timed out, audio glitch count=10 https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.webrtc.fyi%2FMac_Tester%2F44787%2F%2B%2Frecipes%2Fsteps%2Fbrowser_tests%2F0%2Fstdout
,
Nov 14 2017
maxmorin@'s patch below just fixed it: https://chromium.googlesource.com/chromium/src/+/7462d37a1dd834a99cf4c0bf6df60bbaa992fc2b |
||||
►
Sign in to add a comment |
||||
Comment 1 by mcasas@chromium.org
, Jul 13 2016Components: Internals>Media>Audio
Owner: servolk@chromium.org
Status: Assigned
Summary: audio_sync_reader and audio_input_sync_writer WARNING floods output (was: audio_sync_reader WARNING floods output)