- From: Brad Isbell via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Mar 2021 22:52:58 +0000
- To: public-webrtc-logs@w3.org
Please, do not spec a set of default constraints or channel counts. Give us whatever the underlying system gives us for channel count, frame size, frame rate, etc. It knows better than the user agent does. Perhaps a stereo audio input device switches to a mono mode when the user agent assumes mono with no constraints given. The web application doesn't know that this is undesirable as it just wants the default behavior of the audio device. The web application isn't going to request stereo, because it may end up with a wasteful upmix of mono audio devices to stereo. By setting defaults rather than letting the underlying system figure it out, preventing us from rolling with a sensible default, perhaps even a user-configured one at the system level. > As an example, the spec does not say whether, if echoCancellation is supported, echoCancellation should be on or off. > I would guess browsers turn echo cancellation on by default, and many applications are relying on it. They do, and the effects have been very bad for audio quality. I feel strongly that audio on the web would be better off if these options were not enabled by default. If there is any doubt, you can watch any news broadcast from COVID times with remote guests behind some WebRTC-based call. Even if they use an IFB/IEM/earphone with no possibility for feedback, audio quality is damaged because these algorithms were enabled by default and few developers know to turn them off. I believe the base specification should not be assuming use cases, like echoCancellation-by-default does. Default constraints are even worse in that they make assumptions about the use case, the hardware capabilities, the user preferences, and the application intent. Ideally, the web layer is as thin as reasonable, to give us a cross-platform API that interferes as little as possible. To that end, I think the default channelCount, and other stream constraints, should not be put into the spec. If an implementer needs to set default constraints for some reason, such as the base system not supporting a default stream format from the capture device, then they should also be free to do that as they see fit. -- GitHub Notification of comment by bradisbell Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/775#issuecomment-788368288 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 March 2021 22:53:00 UTC