Closed Bug 1421944 Opened 2 years ago Closed 2 years ago
Webrtc microphone input broken in Windows Insider Preview Build 17046
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171129220149 Steps to reproduce: Install Windows Insider Preview build 17046 Install and run Firefox Open https://mozilla.github.io/webrtc-landing/gum_test.html Click audio Allow access to the microphone Actual results: Can hear the microphone input, and the time on the media player increases Expected results: Opt: Cannot hear microphone input, time does not increase Debug: tab crashes - see attached log
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
See Also: → 1418694
I see the failure in the logs: 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1646: (000001EEEC95DA60) Setup capture: device=000001EE80EB30B0 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1587: Setup requested=[f=2 r=48000 c=1 l=undefined] mix=[f=2 r=48000 c=1 l=mono] 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1597: Unable to initialize audio client for capture: 80070005.
I just faffed around with mozregression, and I cannot find a good build (checked back to early 2016). Also, disabling sandboxing works around the failure.
That makes sense because error 0x80070005 is E_ACCESSDENIED - General access denied error. I will pass it on sandbox to tell us what they think. P.S. bug 1418694 in "See also" is a different case, it may be better to remove it in order to avoid any confusion.
Component: WebRTC: Audio/Video → Security: Process Sandboxing
ni to david for some investigation.
OS: Unspecified → Windows
Hardware: Unspecified → All
In bug 1422971 I also noted that it works fine for me with Fx 57 as long as e10s is off. Once e10s is on mic access no longer works. Probably the sandbox for the content process is different/stricter?!
There is no sandbox when e10s is off.
Cubeb remoting on Windows should solve this. We can always hack a work around if that code isn't ready and this bug shows up in a release version of Windows.
(In reply to Jim Mathies [:jimm] from comment #9) > Cubeb remoting on Windows should solve this. What is the bug number for that? How far are we from landing this? And can it get uplifted to release (see below)? > We can always hack a work > around if that code isn't ready and this bug shows up in a release version > of Windows. This is not very well explained in this bug, but over in the bug 1422971 I explained that this change in Windows affects also current release. My current assumption (= worst case scenario) is that Microsoft as some point in the near term future will make Preview Build 17046 the next Win 10 update and at that point all Firefox users who have e10s turned on will loose access to their microphones. From my point of view that would be a pretty catastrophic regression for gUM/WebRTC. To prevent that regression from happening I see the following options: #1) somehow contact Microsoft and ask them to revert what ever change in Win 10 Preview Build 17046 causes this problem #2) try to adjust the Firefox sandbox to the change in Win 10 Preview Build 17046 and uplift that change to Fx release #3) turn off Firefox sandbox via user prefs (not sure if that's possible) if worst comes to worst ... probably I'm missing other/more options here. But looking at the above I don't think that waiting for "Cubeb remoting on Windows" to land is an acceptable solution to the problem.
handyman - I spoke to padenot and he said that it is  that is failing, so it doesn't appear to be the same issue as we once had for NPAPI (which makes sense because that fix has already been implemented for cubeb as we discussed).  https://hg.mozilla.org/mozilla-central/file/f1329009bf0da7b40229ea75ffe18f201b71359e/media/libcubeb/src/cubeb_wasapi.cpp#l1606
Yeah, this is more complex than I initially thought. I don't have a solution in mind yet but here is a brain dump: * I was initially misled by the other E_ACCESSDENIED error in the attached debug log. Its probably not relevant but there is a "Setup render" (audio output) request that fails before the "Setup capture" (mic input) request that is this bug. The failure is in the device enumeration, as it was in Flash . > 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1679: (000001EEEC95DA60) Setup render: device=0000000000000000 > 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1587: Setup requested=[f=2 r=48000 c=2 l=undefined] mix=[f=2 r=48000 c=2 l=stereo] > [...] > 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1013: Could not register endpoint notification callback: 80070005 > 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1866: failed to register notification client, 80070005 * The IMMDevice::Initialize command fails for the mic but succeeds for the aforementioned output device. This suggests that the system is distinguishing between them, which means that it may not be easily finessed. But since we are dealing with a new one-OS-version issue, finesse is still on the table. In particular, IMMDevice::Initialize may be failing but there are other ways to get at a IAudioClient object that _could_ succeed . We could use IMMDeviceEnumerator::GetDevice  -- if we had the device name -- which we are probably blocked from since its the same API that causes the render setup above to fail. However, we can very easily get that name from the parent process. Something to try. * If MS is honestly blocking access to the device and don't agree to revert that then we are in some trouble. I can look into what it is about the sandbox that breaks this but samlh's statement that "I just faffed around with mozregression, and I cannot find a good build (checked back to early 2016)" is discouraging. Some kind of aggressive remoting of behavior would be warranted (if possible) over dialing the sandbox back that far. ------  https://searchfox.org/mozilla-central/rev/ff462a7f6b4dd3c3fdc53c9bc0b328f42a5b3d2b/dom/plugins/ipc/PluginUtilsWin.cpp#50  https://msdn.microsoft.com/en-us/library/windows/desktop/dd370865(v=vs.85).aspx  https://msdn.microsoft.com/en-us/library/windows/desktop/dd371402(v=vs.85).aspx
Hi, Windows audio quality guy here This is due to a bug in Windows audio service; we have a fix for it locally and we're testing it out. What's happening is that the audio service is internally impersonating the app (the Firefox content process) and then calling into another component to verify that the app has access to the microphone; but because the Firefox content process is (correctly) running with a restricted token, the call to the other component is blocked, and the ERROR_ACCESS_DENIED is fallout from this.  https://blogs.msdn.microsoft.com/matthew_van_eerde/
Hey Bob, looks like Matthew may be our savior here ^^.
Flags: needinfo?(davidp99) → needinfo?(bobowencode)
(In reply to David Parks (dparks) [:handyman] from comment #14) > Hey Bob, looks like Matthew may be our savior here ^^. \o/ Thanks for letting us know Matthew, do you have any idea when the fix might make its way into the preview build?
Flags: needinfo?(bobowencode) → needinfo?(mvaneerde)
Whiteboard: Windows Redstone 4, due H1 2018 → Windows Redstone 4, due H1 2018, sb+
Builds 17073 and later have the fix
Sam - Insider Preview Build 17074 has just been announced. This should have the fix, would you mind confirming this?
Flags: needinfo?(jmathies) → needinfo?(samuel.l.harrington)
Yes, I can confirm both the test page and the original page I was trying (https://voice.mozilla.org/record) are now fixed. This is with windows 10.0.17074 Build 17074 and Firefox 59.0a1 (2018-01-10) (64-bit).
(In reply to samlh from comment #18) > Yes, I can confirm both the test page and the original page I was trying > (https://voice.mozilla.org/record) are now fixed. > > This is with windows 10.0.17074 Build 17074 and Firefox 59.0a1 (2018-01-10) > (64-bit). Excellent, thanks for checking and for the original bug report. As this is an OS fix, I think it's safe to mark all Firefox versions fixed.
You need to log in before you can comment on or make changes to this bug.