Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional description of audioLevel #288

Merged
merged 2 commits into from
Jan 17, 2018
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions webrtc-stats.html
Original file line number Diff line number Diff line change
Expand Up @@ -1996,6 +1996,23 @@ <h2>
level = -round(log10(audioLevel) * 20), with audioLevel 0.0 and values above 127
mapped to 127.
</p>
<p>
The <a>audioLevel</a> represents the output audio
level of the track; thus, if the track is sourced
from an <a>RTCReceiver</a>, does no audio
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: RTCRtpReceiver

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did this metric not report on the input and an output audio level?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or at least there should be a section on input audio level as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

processing, has a constant level, and has
a <a>volume</a> setting of 1.0, the audio level is
expected to be the same as the audio level of the
source SSRC, while if the <a>volume</a> setting is
0.5, the audioLevel is expected to be half that
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this go against @vr000m's recommendation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure which recommendation you're referring to.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My expectation was that input audio level and output level would match. And if someone did not hear anything then the volume stat being 0 would identify the problem.

I am trying to see now if we compare the input audio level with the audio output level and the audio output takes the volume into account, how do I diagnose if the issue is with the post decoding filter...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You ask for a solution to #271

value.
</p>
<p>
The audioLevel is averaged over some small
interval, using the algortihm described
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "small interval" part is new; what was the assumption before? That it was just the last decoded/sent packet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous assumption was that it wasn't mentioned; I think the code averaged over a packet. This leaves it specified as "implementation defined", but the averaging has to use the sum-of-squares method rather than just averaging (averaging gives a completely bogus number).

under <a>totalAudioEnergy</a>. The interval used is
implementation dependent.
</p>
</dd>
<dt>
<dfn><code>totalAudioEnergy</code></dfn> of type <span class=
Expand Down