Robotic audio (without loss) sometimes when jitterbuffer drops to near zero

[Faraz Khan]

Hi,

We are using native webrtc (m43) and are observing that sometimes users complain of robotic voice without any real packet loss. What seems strange is that the jitterbufferMS stat drops to some extremely low numbers (4ms?). I dont exactly understand how webrtc works but if someone can shed light on this it'll be great. Is this a bug? How is a 4ms jitter buffer sustainable? The robotic voice complain matches the 4ms low.

Attached a screenshot where we graph the output of GetStats in Grafana. Would using the neteq_impl.cc::SetMinimiumDelay call help force the jitter buffer to a minimum level? 

We can make such changes and report back since we are using webrtc from native c++

Thanks! Also if there is another way to set a minimum jitter buffer or if I'm thinking of it the wrong way please let me know :)

[Henrik Lundin]

Hi Faraz,

Sorry for the delayed answer; my bad.

Jitter buffer level dropping low without any actual packet losses usually indicates that the buffer adaptation did not anticipate an upcoming jitter burst.

What is the preferred jitter buffer size (another metric) in this situation?

In general, I would advice against setting a minimum delay. We'd like the algorithm to adapt by itself to any conditions. Depending on what preferred size you see, we can move forward with different alternatives.

/Henrik

--

---
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/ae3468fb-a349-4ab4-94ee-de4aacf76ad1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Faraz Khan]

Henrik,

Thanks a lot for responding! We arent gathering that stat since we didnt know what it was for :( but are gonna start and report back!

The problem we experience is that wifi in a crowded corporate office can saturate and become very bursty - this happens in sporadic bursts so maybe one way to counter it would be have a minimum jitter buffer so that users dont feel the spike. In some situations having a 200ms or 500ms delay might be a preferable solution to having sporadic repeating drops. What would you think would be the best solution here?

[Baskar]

Hi ,

I am working on some experiments with jitter buffer for audio by using WebRTC.

I basically want to use a adaptive jitter buffer for my voice processing experiment, rather than static. So I am trying to separate AJB from NetEQ only for voice processing. Actually I am able to insert and extract packets from NetEQ by using unitest.cc. Later started to validate for jitter scenarios. 

I have used neteq_impl.cc::SetMinimiumDelay as 100ms and neteq_impl.cc::SetMaximumDelay as 500ms. I delayed packet intentionally and analyzed preferred jitter buffer size. It seems always constant. I went through the flow and able to see value of target_level is always same in my case (i.e) preferred buffer size. 

Not sure is there any configuration mismatch or i really missing some basic understanding here.  Also not clear that how preferred buffer size is adjusting the actual buffer size (i.e) how buffer is automatically adjusted based on preferred buffer size while inserting a packet. 

Any clues or direction would be really helpful for my analysis. Please let me know.  

Thanks  in advance.