Comment on attachment 9039049 [details]
Bug 1521577 - Don't block a MediaStream where at least one track is pulled. r?achronop
Beta/Release Uplift Approval Request
Feature/Bug causing the regression
User impact if declined
Delayed audio from microphone when using microphone and camera
Is this code covered by automated tests?
Has the fix been verified in Nightly?
Needs manual test from QE?
If yes, steps to reproduce
This is tricky to reproduce. It is triggered by a camera that is slow to start. We've seen it appear mostly on linux but other platforms are in theory affected as well. A slow and/or busy machine could also be making it worse. Try different combinations of cameras, machines and load on linux and you should be able to reproduce.
Set the pref "media.cubeb.sandbox" to false (it could add further delay that makes it impossible to regression test)
Go to https://mozilla.github.io/webrtc-landing/gum_test.html
Approve the request with the camera/mic combination you want to test
Approximate the delay by tapping the microphone
If there's noticable delay (0.5s+) without the fix, it's worth testing the fix in the same environment
List of other uplifts needed
Risk to taking this patch
Why is the change risky/not risky? (and alternatives if risky)
It makes a change to when we block a stream vs when we let it continue although one track doesn't have enough data (if done wrong this would make audio and video become out of sync). The context in which this change applies is very narrow, which is why it's low risk. I've done an audit and it only applies to streams from GetUserMedia where both audio and video were requested at the same time, i.e., the very case this is fixing. This case is entirely real-time so it's not possible to go out of sync with this fix.
String changes made/needed