Additional description of audioLevel #288
Conversation
Fixes #239 (by answering "yes").
| 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 |
There was a problem hiding this comment.
Doesn't this go against @vr000m's recommendation?
There was a problem hiding this comment.
Not sure which recommendation you're referring to.
There was a problem hiding this comment.
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...?
There was a problem hiding this comment.
You ask for a solution to #271
webrtc-stats.html
Outdated
| </p> | ||
| <p> | ||
| The audioLevel is averaged over some small | ||
| interval, using the algortihm described |
There was a problem hiding this comment.
This "small interval" part is new; what was the assumption before? That it was just the last decoded/sent packet?
There was a problem hiding this comment.
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).
| <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 |
There was a problem hiding this comment.
did this metric not report on the input and an output audio level?
There was a problem hiding this comment.
Or at least there should be a section on input audio level as well.
| <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 |
There was a problem hiding this comment.
did this metric not report on the input and an output audio level?
| <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 |
There was a problem hiding this comment.
Or at least there should be a section on input audio level as well.
| 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 |
There was a problem hiding this comment.
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...?
|
Need to add text saying that for outgoing tracks, it's the audio level transmitted into the PeerConnection. |
|
That volume is a range is an accident of the constraint syntax. It should mean, formally, that the UA is going to pick a number within that range; it would be rather silly of the UA to not pick the middle. |
Fixes #239 (by answering "yes").