STRs: 1. Establish a WebRTC 1-1 call on https://appear.in/someroom345234 or similar 2. In a separate (process) tab, open a google doc with something meaty to scroll. 3. Scroll google doc up and down continuously while talking. Expected result: - Other caller hears you fine (no difference whether scrolling or not). Actual result: - Other caller hears continuous audio stuttering only while scrolling. Basically, audio is under-running consistently while scrolling a random tab. Profiling content process for 30-40 seconds shows we're waiting for a Monitor in MediaEngineRemoteVideoSource::NotifyPull for about ~75% of the audio callback (*) Weight Self Weight Symbol Name 26.13 s 1.5% 0 s plugin-container (40821) 22.13 s 1.2% 0 s nsThread::ThreadFunc 0x566699 22.13 s 1.2% 0 s thread_start 22.13 s 1.2% 0 s _pthread_start 22.13 s 1.2% 0 s _pthread_body 22.13 s 1.2% 0 s _pt_root 22.13 s 1.2% 0 s nsThread::ThreadFunc(void*) 22.13 s 1.2% 0 s MessageLoop::Run() 22.13 s 1.2% 0 s mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 22.13 s 1.2% 0 s NS_ProcessNextEvent(nsIThread*, bool) 22.13 s 1.2% 0 s nsThread::ProcessNextEvent(bool, bool*) 22.13 s 1.2% 0 s mozilla::ipc::MessageChannel::MessageTask::Run() 22.13 s 1.2% 0 s mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) 22.13 s 1.2% 0 s mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) 22.13 s 1.2% 70.00 ms mozilla::camera::PCamerasChild::OnMessageReceived(IPC::Message const&) 22.06 s 1.2% 0 s mozilla::camera::CamerasChild::RecvDeliverFrame(mozilla::camera::CaptureEngine const&, int const&, mozilla::ipc::Shmem&&, mozilla::camera::VideoFrameProperties const&) 22.06 s 1.2% 10.00 ms non-virtual thunk to mozilla::MediaEngineRemoteVideoSource::DeliverFrame(unsigned char*, mozilla::camera::VideoFrameProperties const&) 22.05 s 1.2% 60.00 ms mozilla::MediaEngineRemoteVideoSource::DeliverFrame(unsigned char*, mozilla::camera::VideoFrameProperties const&) 9.60 s 0.5% 0 s webrtc::I420Buffer::CropAndScaleFrom(webrtc::VideoFrameBuffer const&, int, int, int, int) 9.60 s 0.5% 0 s I420Scale 9.60 s 0.5% 30.00 ms ScalePlane 9.57 s 0.5% 150.00 ms ScalePlaneBilinearDown 6.24 s 0.3% 6.24 s ScaleFilterCols_SSSE3 3.18 s 0.1% 3.18 s InterpolateRow_AVX2 4.51 s 0.2% 0 s webrtc::ConvertToI420(webrtc::VideoType, unsigned char const*, int, int, int, int, unsigned long, The code around this lock changed to be held open during the meat of DeliverFrame() in bug 1388219 in 59, which we believe is the regression. That said, I haven't run mozregression yet, but this looks like the problem. Andreas to take since he's basically fixes this already in bug 1299515, but we need a patch to uplift to 59, hence this issue. *) Assuming we're reading the seconds column right (the %s are a bit off). I'll attach the profile. This was with ☑ Recording Waiting Threads in OSX's Instruments Time Profiler.

Sorry I had a filter on when doing that dump. Here's the part showing the lock: Weight Self Weight Symbol Name 20.16 s 1.1% 60.00 ms AUHAL::AUIOProc(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) 19.42 s 1.1% 20.00 ms AUBase::DoRender(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int, AudioBufferList&) 19.40 s 1.1% 10.00 ms AUBase::DoRenderBus(unsigned int&, AudioTimeStamp const&, unsigned int, AUOutputElement*, unsigned int, AudioBufferList&) 19.32 s 1.1% 20.00 ms AUConverterBase::RenderBus(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int) 19.26 s 1.1% 50.00 ms audiounit_output_callback(void*, unsigned int*, AudioTimeStamp const*, unsigned int, unsigned int, AudioBufferList*) 19.13 s 1.1% 10.00 ms passthrough_resampler<float>::fill(void*, long*, void*, long) 19.07 s 1.1% 10.00 ms mozilla::AudioCallbackDriver::DataCallback(float const*, float*, long) 11.37 s 0.6% 10.00 ms mozilla::MediaStreamGraphImpl::OneIteration(long long) 9.10 s 0.5% 60.00 ms mozilla::MediaStreamGraphImpl::UpdateGraph(long long) 4.63 s 0.2% 20.00 ms mozilla::SourceMediaStream::PullNewData(long long, nsTArray<RefPtr<mozilla::MozPromise<bool, bool, true> > >&) 4.27 s 0.2% 20.00 ms mozilla::MediaStreamListener::AsyncNotifyPull(mozilla::MediaStreamGraph*, long long) 3.62 s 0.2% 10.00 ms mozilla::MediaEngineRemoteVideoSource::NotifyPull(mozilla::MediaStreamGraph*, mozilla::SourceMediaStream*, int, long long, nsMainThreadPtrHandle<nsIPrincipal> const&) 2.90 s 0.1% 0 s mozilla::detail::MutexImpl::lock() 2.90 s 0.1% 0 s _pthread_mutex_lock_wait 2.90 s 0.1% 2.90 s __psynch_mutexwait The numbers are less significant than at first assumed, but 3 seconds waiting on a lock in 30 second run is still bad.

Updated STRs: 1. First, open https://jsfiddle.net/jib1/m9gbqqfz/ in a new tab, share cam, and leave it running. 2. In a second tab, open https://jsfiddle.net/yxbLvjm6/ and share cam; Use headset and talk to hear yourself. 3. In third tab, open a google doc with something meaty to scroll. 4. Scroll google doc up and down continuously while talking. Expected: no audio stutter, actual: audio stutter. After I had trouble reproing comment 0 in a new Firefox instance, I noticed DeliverFrame in comment 0 was calling CropAndScaleFrom() [1], which it shouldn't be doing. That code-path should only run when there's concurrent simultaneous camera access. It's downscaling every camera frame from the camera resolution to a lower requested resolution, so that's a significant difference in overhead. I've verified on a clean (different profile) instance this doesn't happen normally: Weight Self Weight Symbol Name 119.00 ms 0.5% 1.00 ms non-virtual thunk to mozilla::MediaEngineRemoteVideoSource::DeliverFrame(unsigned char*, mozilla::camera::VideoFrameProperties const&) 118.00 ms 0.5% 0 s mozilla::MediaEngineRemoteVideoSource::DeliverFrame(unsigned char*, mozilla::camera::VideoFrameProperties const&) 114.00 ms 0.4% 1.00 ms mozilla::layers::SharedPlanarYCbCrImage::CopyData(mozilla::layers::PlanarYCbCrData const&) This suggests something is broken in CamerasParent's logic around what different-constraint camera requests are outstanding (it appears stuck in downscale mode). Anyway, the new STRs above adds a second fiddle that opens the camera in two different resolutions, forcing downscaling, which seems to add enough load to trigger the audio stutter, and I can repro it now. [1] https://searchfox.org/mozilla-central/rev/97cb0aa64ae51adcabff76fb3b5eb18368f5f8ab/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp#489,515