Using getStats to get track volumes

[Matt Toschlog]

I just read Henrik Boström's "Intent to Deprecate" post in blink-dev, and he says that a common use case is to "poll getStats() at 10 Hz and render volume bars for each participant based on volume levels from stats objects."

I have volume indicators in my app, and I'm computing the volume myself using a scriptProcessor.  Is getStats() a better way to do it?  If the stats gatherer is already doing the work, perhaps I don't need to duplicate it.

(I do realize that the scriptProcessor stuff is deprecated and I should switch to audioWorklet, but I haven't done that yet.)

Thanks.

[Philipp Hancke]

getStats is *not* the better way. It is relatively heavy in terms of memory and objects it allocates (even if you just query an rtp sender/receiver)

https://webrtccourse.com/course/webrtc-codelab/module/fiddle-of-the-month/lesson/checking-audio-levels/

from a while back compares the three alternatives, getSynchronizationSources (or its evil twin getContributingSources) are still the preferred way I think

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d1ea4fd7-6a2d-1040-5124-2b8b8fb3a920%40toschlog.com.

[Muhammad Usman Bashir]

Yes, that's correct, Philipp is right.

The `getSynchronizationSources` or `getContributingSources` methods are the preferred way to get audio volume levels in a WebRTC application. These methods are lighter in terms of memory usage and objects allocated compared to the `getStats` method. The `getSynchronizationSources` method provides a way to get the audio levels for a specific audio track or stream. The `getContributingSources` method provides a way to get the audio levels for all audio sources that contribute to a specific audio track or stream. Both methods are more efficient than the `getStats method for this specific use case.

Here's a JavaScript example using the getSynchronizationSources method:

```

const audioTrack = new MediaStreamTrack("audio", {});
const audioContext = new AudioContext();
const audioSource = audioContext.createMediaStreamSource(audioTrack);
const analyser = audioContext.createAnalyser();

audioSource.connect(analyser);

setInterval(() => {
  const data = new Uint8Array(analyser.frequencyBinCount);
  analyser.getByteFrequencyData(data);
  const volume = data.reduce((sum, value) => sum + value) / data.length;
  console.log("Audio volume:", volume);
}, 100);

```

This example uses the `getSynchronizationSources` method to get the audio volume levels for an audio track. It creates an audio context and connects an audio source to an analyser. The analyser's `getByteFrequencyData` method is used to get the audio volume levels, which are then logged to the console. The example runs this code every 100ms to get updated audio volume levels.

Kind regards, 

[Tore Lading]

Hi All, Thanks for this post. I have been struggling to find a good way of tracking live volume on a wbrtc sender.

Would this also be possible to do on the Android WebRtc platform to your knowledge ?

kind regards

Tore

[Matt Toschlog]

I'm wondering about the computational cost of the various methods.  Currently my code grabs a packet of samples five times a second and computes the volume using the square root of the mean of the squares.  Surely this is cheaper than running the AnalyserNode's FFT?

And what about the getSynchronizationSources() method?  Is that value already being computed so incurs no extra cost?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/bec92d66-21c1-41a0-8a39-bc31d534f4can%40googlegroups.com.