In Chrome 64 proberen we een nieuw gedrag voor getUserMedia-audiostreams waarvoor de echoCancellation -beperking is ingeschakeld. Wat nieuw is, is dat dergelijke streams de hardwareruisonderdrukking tijdelijk uitschakelen gedurende de duur van de stream. We verwachten dat hierdoor de echo-onderdrukker beter zal presteren. Omdat deze functionaliteit experimenteel is, moet deze expliciet worden ingeschakeld; zie hieronder .
Op dit moment wordt dit gedrag alleen ondersteund voor bepaalde invoerapparaten en alleen op macOS. Ondersteuning is beperkt tot apparaten die een inschakelbare “reductie van omgevingsgeluid” hebben in het paneel Geluid van Systeemvoorkeuren .
Achtergrond
Een echo-onderdrukker probeert het geluid dat via de luidsprekers wordt afgespeeld, te verwijderen uit het audiosignaal dat door de microfoon wordt opgevangen. Zonder dit wordt wat u zegt als één partij van een gesprek, opgepikt door de microfoon van de andere partijen en vervolgens naar u teruggestuurd. Je hoort een echo van jezelf!
Om echo succesvol te kunnen verwijderen, moet de echo-onderdrukker van WebRTC (die in Chrome wordt gebruikt) een zo zuiver mogelijk audiosignaal uit de microfoon halen. Verwerking die wordt toegepast voordat de audio de echo-onderdrukking bereikt, zoals hardwareruisonderdrukking, zal normaal gesproken de prestaties ervan belemmeren. Bovendien is er al softwarematige ruisonderdrukking aanwezig, maar pas nadat de echo-onderdrukking zijn verwerking heeft gedaan.
Details van het nieuwe gedrag
Webontwikkelaars kunnen het nieuwe gedrag op hun sites mogelijk maken door zich aan te melden voor een Origin-proefversie . Eindgebruikers kunnen dit wereldwijd inschakelen door een opdrachtregelvlag door te geven bij het starten van Chrome. Zie hieronder voor meer informatie.
Wanneer dit is ingeschakeld en een webpagina getUserMedia aanroept om audio van een invoerapparaat op te halen, gebeurt het volgende:
Als de
echoCancellationbeperking is ingeschakeld, wordt hardwareruisonderdrukking uitgeschakeld voor de duur van de nieuw gemaakte audiostream.Omdat deze instelling voor het hele systeem geldt, is deze van toepassing op alle audio-invoerstromen van hetzelfde apparaat (dwz dezelfde microfoon).
Zodra de laatste stream waarvoor hardwareruisonderdrukking is uitgeschakeld, wordt gesloten, wordt hardwareruisonderdrukking weer ingeschakeld.
Als hardwareruisonderdrukking al eerder was uitgeschakeld, zal Chrome de status ervan niet wijzigen.
Als getUserMedia wordt aangeroepen zonder dat
echoCancellationis ingeschakeld, zal Chrome de hardwareruisonderdrukking niet aanraken.
Omdat deze instelling ook door de gebruiker kan worden beheerd, zijn er enkele specifieke interacties met de gebruiker:
Als Chrome de hardwareruisonderdrukking heeft uitgeschakeld en de gebruiker deze weer inschakelt, zal Chrome niet proberen deze voor die stream opnieuw uit te schakelen.
Als Chrome de hardwareruisonderdrukking heeft uitgeschakeld en de gebruiker deze weer in- en vervolgens weer uitschakelt, zal Chrome deze nog steeds opnieuw inschakelen zodra de stream is beëindigd.
Het gedrag wordt van kracht door simpelweg het experiment in te schakelen. Er zijn geen API-wijzigingen nodig.
Hoe u het experiment kunt inschakelen
Om dit nieuwe gedrag op uw site te krijgen, moet u zich hebben aangemeld voor de Origin-proefversie "Hardwareruisonderdrukking uitschakelen". Als je het gewoon lokaal wilt uitproberen, kan het ook via de opdrachtregel worden ingeschakeld:
chrome --enable-blink-features=DisableHardwareNoiseSuppression
Als u deze vlag op de opdrachtregel doorgeeft, wordt de functie globaal ingeschakeld voor de huidige sessie.
Er zijn een aantal aspecten die we met dit experiment willen evalueren:
Kwalitatieve verschillen, in het veld, tussen het aan- en uitzetten van hardwareruisonderdrukking.
Welke invloed heeft het wijzigen van deze instelling vanuit Chrome op de eindgebruiker en op andere software die deze mogelijk gebruikt?
Wij zijn geïnteresseerd in feedback over beide aspecten. Zijn gesprekken beter of slechter als deze functie is ingeschakeld? Zijn er problemen met de implementatie die onverwacht gedrag veroorzaken? Als u dit uitprobeert, geef dan in ieder geval feedback over deze bug . Vermeld indien mogelijk welke microfoon/headset/etc. is gebruikt en of deze de reductie van omgevingsgeluid ondersteunt. Als u grootschaliger experimenten uitvoert, worden links naar vergelijkende statistieken over de kwaliteit van audiogesprekken op prijs gesteld.