Allow developers to know when noise suppression is active |
|||||
Issue descriptionThe audio level from media stream tracks can be affected by noise suppression on the input. Developers would like to distinguish cases where audioLevel is zero because a corresponding source (f.i. microphone) is not functioning from cases where the source is producing a weak signal that is completely attenuated by noise suppression. This allows developers to alert the user about possible hardware problem. Would it make sense to add statistic for noise attenuation, similar to echoReturnLoss/echoReturnLossEnhancement? Product statistics show that low/zero audioLevel is the most common symptom of audio problems, and there is a strong need to differentiate the different causes.
,
Nov 2 2017
If there is a value like this or an "inputAudioLevel" (before suppression) available it would make sense to surface it in getStats, and a https://github.com/w3c/webrtc-stats/issues issue should be filed. But it sounds like you want to know if it has been zero/low for a long time as opposed to "is the current volume zero?". Some interesting questions: - What if the case of HW noise suppression, the input from the microphone could be zero? - What if a broken mic produces some sound sometimes, such as if you fiddle with it, but not when talking? - What if it is producing sound, but it's just REALLY low? It might be interesting to know... - For what duration of time has the volume been zero? - For what duration of time has the volume been been "low"? - When was the last point in time a noise was recorded? Polling at a regular interval might suffice though. With audio energy you could calculate the average audio volume during an interval, so you could maybe do that.
,
Nov 2 2017
Broken mics and, HW noise suppression will be difficult to identify. But additional information of webrtc noise suppression can be helpful. Potentially the statistic should be audioInputLevelMax, representing the max level the past X seconds. Add a proposal in https://github.com/w3c/webrtc-stats/issues/271
,
Nov 3 2017
We had this problem in the "audio volume too low" investigations a couple of years back in WebRTC land - where we added a thing to the audio driver on Mac (I think) that would let the driver raise the mic volume level if it was close-to-zero. I don't remember the details of how we diagnosed that problem, grunell may remember. It's experience we could learn from, most probably.
,
Nov 8 2017
Setting status as assigned since it has an owner.
,
Nov 24 2017
Is the need for a "look back in time" indicator - ie code notes that there may be a problem, and wants to know what happened recently - or is it for a "diagnose what's happening now" indicator - ie code notes that there may be a problem and wants to run a diagnostic routine to check out what the state is? separately, we need to ensure that it's possible to get the state of noise suppression in getSettings().
,
Nov 24 2017
,
Nov 24 2017
,
Jan 16 2018
I did an experiment with trying to get the track's volume before processing by simple means. It should work according to spec, but it doesn't in Chrome 63 - we apply processing at the source before audio's (conceptually) distributed to the tracks, so it can't be different from different tracks for the same audio device. I have a demo on how it should be able to work in a PR, but it doesn't work yet. Demo: https://github.com/webrtc/samples/pull/993 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by huib@chromium.org
, Nov 2 2017