The range in the link in comment #6 doesn't cover the revert commit (611722). Also, it's Chromium OS, not Linux. (Although it's flaky there too, see dupe in comment #7.)
When I analyze tip of tree in find it's analysis UI, it just stays at "Analyzing" seemingly forever.
The flakiness dashboard in comment #9 shows a few timeouts.
I can't verify the effect of reverting the CL. I think it can be relanded.
Cc: olka@chromium.org yoavweiss@chromium.org maxmorin@chromium.org ossu@chromium.org peah@chromium.org Status: Started (was: Assigned)
From the log[1,2]:
[28196:28279:1210/184952.671292:WARNING:render_delay_buffer2.cc(342)] Applying total delay of 5 blocks.
[28196:28279:1210/184952.682111:WARNING:render_delay_buffer2.cc(314)] Receiving a first externally reported audio buffer delay of 0 ms.
[28196:28279:1210/184952.682309:WARNING:render_delay_buffer2.cc(342)] Applying total delay of 1 blocks.
[28196:28279:1210/184952.682394:WARNING:render_delay_buffer2.cc(239)] New max number api jitter observed at capture block 1: 2 blocks
[28196:28279:1210/184952.683070:WARNING:render_delay_buffer2.cc(239)] New max number api jitter observed at capture block 2: 3 blocks
[28196:28279:1210/184952.683133:WARNING:render_delay_buffer2.cc(257)] Render buffer underrun detected at block 2
[1:25:1210/184952.645861:FATAL:scoped_refptr.h(220)] Check failed: ptr_.
#0 0x7fdd820f8f4d base::debug::StackTrace::StackTrace()
#1 0x7fdd81de9e5a base::debug::StackTrace::StackTrace()
#2 0x7fdd81e5bc3b logging::LogMessage::~LogMessage()
#3 0x7fdd76ed6902 scoped_refptr<>::operator->()
#4 0x7fdd7a10a922 content::WebRtcAudioDeviceImpl::RenderData()
#5 0x7fdd7a115322 content::WebRtcAudioRenderer::SourceCallback()
#6 0x7fdd7a114f19 content::WebRtcAudioRenderer::Render()
#7 0x7fdd74a8dbca media::AudioOutputDeviceThreadCallback::Process()
#8 0x7fdd74a421f7 media::AudioDeviceThread::ThreadMain()
#9 0x7fdd82134d2d base::(anonymous namespace)::ThreadFunc()
#10 0x7fdd55c00184 start_thread
#11 0x7fdd5145803d clone
The only place |renderer_| is used in WebRtcAudioDeviceImpl::RenderData() is for the early DCHECK. So |renderer_| has been invalidated (or never set) when that function is called. This could then be timing dependent.
The warnings before the CHECK is from AEC3. Per, can you explain what those mean? They could be normal, but I didn't see them in the around 15 runs I did locally (which all succeeded).
I don't see any suspicious CLs around the time when the pass rate dropped (revision 611174). Yoav, could it be that your CL changes the timing so that this issue is revealed with that?
Adding Olga and Max if you have any ideas.
[1] https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Tests%20%28dbg%29%281%29/76340
[2] https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8927472331082366912/+/steps/browser_tests/0/stdout
The warnings relate to how the audio pipeline outside of APM/AEC3 behaves and reflect how AEC3 perceives that (API call jitter/render underrun).
These warnings are fully safe for AEC3 should not cause any issues, apart from echo leakage/transparency loss if the external pipeline is behaving too badly.
As far as I can tell there's no guarantee that |renderer_| holds a non-null pointer in this function, hence the lock which protects that variable among other. Fixing the DCHECK, and another DCHECK access that is not under lock.
Comment 1 by dtapu...@chromium.org
, Nov 28