I leave it up to one of hlundin/tlegrand/hta to find an appropriate owner and timeframe for implementation.

Did I understand previous discussion to say that we've actually implemented configurable max jitter buffer on the WebRTC library interface, so that we "just" need a double-valued constraint in the Blink API in order to enable it?

Can someone confirm and say which API (call and struct) in WebRTC it needs to be on in order to be effective?

Hi,

The original post has more information but in short changing kAudioJitterBufferMaxPackets to 100 meant Chrome could handle twice the jitter it can do normally. Increasing this value any further didn't increase the handling of jitter any further.

While allowing us to set kAudioJitterBufferMaxPackets to 100 would be a welcomed quick win, it would be better to look into it properly as the statistics related to the jitter buffer jump around wildly and it doesn't seem to grow and shrink nicely as expected. We can help test any changes you make and build chromium locally if needed.

I spotted something in Chrome logging

AudioOptions {aec: true, agc: true, ns: true, hf: true, swap: false, audio_jitter_buffer_max_packets: 50, audio_jitter_buffer_fast_accelerate: false, typing: true, agc_delta: 0, experimental_agc: false, extended_filter_aec: false, delay_agnostic_aec: false, experimental_ns: false, aec_dump: false, }


These look relevant:

audio_jitter_buffer_max_packets
audio_jitter_buffer_fast_accelerate

can they be set in the javascript somehow? 

No, they cannot be set from javascript today, but audio_jitter_buffer_max_packets is the C++ config that hta@ is asking for in #3.

Is there a simple translation between audio_jitter_buffer_max_packets and the latency (seconds) that is described as a constraint in the spec?

if kAudioJitterBufferMaxPackets is currently setting audio_jitter_buffer_max_packets then yes we found that increasing  kAudioJitterBufferMaxPackets from 50 to 100 doubled the amount of latency volatility that the Jitter Buffer could handle. This would be a good start to improving this.

A translation between audio_jitter_buffer_max_packets and the latency (seconds) requires knowing the frame size (ms) of the audio packets. This may not be known, and it is also conceivable that it changes over the course of a call.

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

hlundin@ can you help with triage here?

Regarding the tuning of the jitter buffer itself: this is a long-term project. I can't say much more than to stay tuned.