- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Jun 2018 12:43:43 +0000
- To: public-media-capture-logs@w3.org
The problem with instantaneous values is audio level could change in-between polling. Audio level is, at least conceptually, a continuum over time and you can't get around discrete polling, but the total audio energy allows you to, by polling it twice, calculate the average audio level by looking at the difference and diving by time, similar to how polling a total counter of bytes twice and dividing the difference with time gets you bps. I don't fully understand the math when it comes to audio energy but it might be a good idea. On the other hand if audio level is something we always have access to maybe polling frequently is not an issue for performance (unlike RTCPeerConnection.getStats() which is expensive) and it's better to have something easy-to-use and easy-to-grasp. In any case the metrics of interest might be... 1. The volume of the data produced by the device (browser level). 2. The volume of the data coming in to the track. 3. The volume of the data after track-specific processing, e.g. constraints, removing noise, etc. If no processing happens between 1 and 2 and they are the same, or if 1 is not of interest, we are just talking about "inputAudioLevel" (2) and "outputAudioLevel" (3). -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/523#issuecomment-399090425 using your GitHub account
Received on Thursday, 21 June 2018 12:43:46 UTC