Provide a mean to measure the gain with parallelized audio decoding

Assigned to



WebRTC: Audio/Video
a month ago
a month ago


(Reporter: jya, Assigned: jya)


Firefox Tracking Flags

(Not tracked)




a month ago
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.


a month ago
Assignee: nobody → jyavenard
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)
Rank: 25
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.