Intent to Experiment: Disable Hardware Noise Suppression

[os...@chromium.org]

Contact emails

os...@chromium.org

Explainer

https://docs.google.com/document/d/e/2PACX-1vRYEUohUdK-c_l0W8JyyAoYC7luae6fm498OpVHF6wtdVoRUkK57Lzakcb2fJFTSo2awzCFdPlL7a9s/pub

Summary

Change the behavior of Chrome with regard to the echoCancellation constraint of getUserMedia. When this constraint is enabled, and the page has enabled the origin trial, hardware noise suppression will be turned off for the duration of the stream. For this experiment, support will only be available on macOS.

Primarily, this allows WebRTC to rely on its internal noise suppressor, which should have a less deleterious effect on echo cancellation and audio quality.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/NMg2ZFxmsCg

Goals for experimentation

To evaluate the impact on, primarily audio, performance with and without this built-in processing. Running as an origin trial will enable sites to revert to the previous behavior if it turns out this new one is causing problems.

Experimental timeline

We want to start the experiment in M64 beta and run until M65.

Any risks when the experiment finishes?

Very low to none. Built-in noise suppression is not currently software-controllable from within Chrome, but is user-controllable. Applications are thus already expected to perform reasonably with or without this feature.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Initially only on Mac. If the trial results are positive, we’ll look towards extending this functionality to other platforms where we may control hardware processing.

Link to entry on the feature dashboard

The change itself is very small and shouldn’t require a separate feature. There are already a couple of features pertaining to the implementation of media constraints.

[Rick Byers]

I assume you're working with a particular customer who wants to test this change out on their users in the wild (not just in the lab), right?  If so that sounds like a great use of OT to me - LGTM.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ea50adc8-982f-49b1-885a-92f6f0eff610%40chromium.org.

[os...@chromium.org]

That's right. We're specifically testing this through Hangouts, but welcome feedback from other users as well.

[os...@chromium.org]

We're having a discussion on the appropriate place to track feedback for this experiment. Would pointing users to https://github.com/w3c/mediacapture-main/issues make sense?

I think creating a specific tracking issue on there and pointing users directly to it would help keep the feedback in one place. Since it's a pretty small change, I don't anticipate the need for tracking separate issues arising from it.

[Rick Byers]

Sounds reasonable to me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/106d8ebe-0ff2-484c-8d60-446d822594d0%40chromium.org.