Issue metadata
Sign in to add a comment
|
RTCStats: Local audio track defined by outgoingrtp has constant audioLevel 0
Reported by
rrowl...@twilio.com,
Jun 23 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.40 Safari/537.36 Steps to reproduce the problem: 1. Connect to a two-way audio call over WebRTC. 2. Call getStats() while making noise in the active microphone 3. Get the track ID from outboundrtp and find the associated track report 4. Verify that the audioLevel field is always 0 What is the expected behavior? audioLevel should increase based on the volume of audio being transmitted What went wrong? audioLevel is constantly at 0, despite hearing audio on the other end of the call. Analyzing audio through an AudioContext also reveals non-zero actual audio levels. Did this work before? Yes In the legacy goog-prefixed WebRTC stats, the equivalent field was populated Does this work in other browsers? Yes Chrome version: 60.0.3112.40 Channel: beta OS Version: OS X 10.12.5 Flash Version:
,
Aug 11 2017
guidous@ hbos@ Has this been looked into at all? Is there any other information I can provide to help triage?
,
Aug 14 2017
I don't know about the lower layer audio magic, but the stats collector gets its values from webrtc::AudioSend/ReceiveStream::Stats @solenberg can you take a look or reassign? git blame shows you wrote stats.audio_level = channel_proxy_->GetSpeechOutputLevelFullRange(); and stats.audio_level = base->transmit_mixer()->AudioLevelFullRange(); https://cs.chromium.org/chromium/src/third_party/webrtc/audio/audio_receive_stream.cc?type=cs&q=/audio/audio_receive_stream.cc&sq=package:chromium&l=189 https://cs.chromium.org/chromium/src/third_party/webrtc/audio/audio_send_stream.cc?type=cs&q=audio/audio_send_stream.cc:314&sq=package:chromium&l=314
,
Sep 27 2017
solenberg@ are you looking at this?
,
Oct 25 2017
Ping.
,
Feb 2 2018
Ping. hbos@ guidous@ solenberg@
,
Feb 7 2018
I can verify the bug but it doesn't look like it has to do with the lower layers indicated in #3; if I connect two appr.tc clients, indeed outgoingrtp audioLevel stays at zero, however webrtc-internals displays the accurate audioInputLevel. So it seems the legacy getStats() interface used in webrtc-internals works, but the new API is broken. hbos@, can you point at the relevant unit test(s)?
,
Feb 8 2018
The new getStats API has this audioLevel: https://cs.chromium.org/chromium/src/third_party/webrtc/api/stats/rtcstats_objects.h?sq=package:chromium&dr&l=290 Which it gets from Voice[Sender/Receiver]Info.audio_level, in the local (sender) case: https://cs.chromium.org/chromium/src/third_party/webrtc/media/base/mediachannel.h?sq=package:chromium&dr&l=387 There are unittests for the new statscollector, RTCStatsCollector, based on mock/fakes here: https://cs.chromium.org/chromium/src/third_party/webrtc/pc/rtcstatscollector_unittest.cc?q=rtcstatscollector_unittest.cc&sq=package:chromium&dr&l=1215 Which tests that we get specific values. And there is an integrationtest that sets up a call and verify that we get stats, but that only guards against nonsense values, such as audioLevel must not be negative rather than expecting something more specific: https://cs.chromium.org/chromium/src/third_party/webrtc/pc/rtcstats_integrationtest.cc?q=rtcstats_integrationtest.cc&sq=package:chromium&dr&l=556
,
Sep 30
Issue webrtc:9775 has been merged into this issue. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by guidou@chromium.org
, Jun 26 2017Status: Assigned (was: Unconfirmed)