User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170814072924 Steps to reproduce: case 1.we use the demo https://webrtc.github.io/samples/src/content/getusermedia/audio/ to play local audio to test the audio delay. case 2: we use the demo https://webrtc.github.io/samples/src/content/peerconnection/audio/ to play local audio to test the audio delay. Actual results: 1.we find that the audio delay 3 seconds after 15 hours in case 1 2.we find that the audio delay 4 seconds after 15 hours in case 2

xpeng, are you on windows when doing those tests? I've written a patch for windows yesterday that should make things better.

(In reply to Paul Adenot (:padenot) from comment #1) > xpeng, are you on windows when doing those tests? I've written a patch for > windows yesterday that should make things better. yes , we test it on windows, how can i get the patch for testing?

It'll be in Firefox Nightly soon, I'll let you know in this bug.

(In reply to Paul Adenot (:padenot) from comment #3) > It'll be in Firefox Nightly soon, I'll let you know in this bug. OK We will test it as soon as possible while the patch is ready.

Can we test it using the current firefox nightly ?

Nope, sorry, not yet. I'll let you know.

Likely this will be duped, but prioritizing it separately for now.

Mass change P1->P2 to align with new Mozilla triage process

We've had a couple of bug reports on audio drift. We're picking this one to track work Paul is doing to avoid long-term drift in cubeb here: issue https://github.com/kinetiknz/cubeb/issues/353 pr is https://github.com/kinetiknz/cubeb/issues/354

Mirroring comment I made on github, about the "right" way to really solve this. Likely not that surprising... FYI, from chatting on Slack: The "right" way to do it is to a) resample to match rates, b) keep enough buffer to avoid underruns, but no more. This obviously can fail if the environment/load changes, which is why it has to be adaptive (basically it has to be a form of jitter buffer). In most cases, it should run at "no extra buffering" (i.e. we haven't seen underruns) which means max one capture "frame" (typ 10ms or less - and if you're not having to resample (no drift), it should be 0 in that case. When the buffer starts to grow, you slew the resample rate to stop the growth and get it back near your target depth. If you see underruns, you glitch, and you slew the resample rate to increase the amount of buffering (and bump the target for buffering probably). This is classic jitter-buffer design. For "extra" fancy, you can minimize pitch warbles when slewing (and slew faster) by using some of the magic in NetEq to add or remove cycles of the dominant frequency (TDC - Time Distortion Compensation IIRC) IMHO

xpeng, this is now in Nightly, please have a look, and tell us what you think! Thanks!

(In reply to Paul Adenot (:padenot) from comment #12) > xpeng, this is now in Nightly, please have a look, and tell us what you > think! Thanks! OK , we will test it soon.

we have checked it with demo below for 21 hours, It works fine: https://webrtc.github.io/samples/src/content/peerconnection/audio/ https://webrtc.github.io/samples/src/content/getusermedia/audio/

xpeng, I'm marking this one as fixed. Thanks for reporting and testing the fix!

Updated tracking flag to match bug 1405258 comment 11.