In bug 1404997 we now have a parallelized audio decoding happening. It would be good to have a way to determine the gain it provides. One possibility would be for a time, run both codes alternatively and measure the latency/time between a looping, synchronous audio decoding and a parallel version. We could report that time through telemetry. How it would be reported is to be determined. We could imagine reporting the average decoding time of a call based on the number of peers, capped at say 16 peers.

Assigning a call (or a user) to one or the other might work if you want to experiment with this in the field (or do it via Shield). Then measure latency (and number/frequency of underruns) and add to telemetry. The slope of improvement and where it stops will be interesting (and in telemetry it will not look like a hard cut-off, since number of cores vary and also load on the system (and browser) outside of webrtc). Also very interesting will be the impact on 1:1 calls (in particular latency)