New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 17 users

Issue metadata

Status: Assigned
Vacation until August 6
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 1395

Sign in to add a comment
This issue has been classified as spam. Please report incorrect spam classification.

Re-enable support for clock drift compensation on Windows

Project Member Reported by, Aug 24 2012

Issue description

Clock drift compensation was somehow disabled in the distant past when CLOCK_SKEW_COMP was no longer defined. This needs to be enabled again on Windows.
Project Member

Comment 1 by, Aug 24 2012

CL up for review:
I'm curious about how this feature can be manually/automatically tested and verified in a web browser. Can anyone elaborate on that?
Project Member

Comment 3 by, Aug 27 2012

Manual is quite easy: run on a setup known to exhibit clock drift and check if you get echo. On Windows 7 this should be possible by setting one of the capture/render rates to 44.1 kHz and the other to 48 kHz, for example.

Automatic is harder, as usual, since it involves analyzing the audio. It could probably be done by using the echo statistics (ERL etc) voice engine provides, on a bot configured to actually render and capture audio.
So, should we prioritize getting such a setup up for manual testing? 
Should it be tested on Mac and Linux as well?

Comment 5 by, Sep 11 2012

Sure, although for the example I gave, there shouldn't be much to do. Any existing Windows machine will work. Many (most?) devices can be set to a 44.1 kHz sampling rate.

Comment 6 Deleted

Project Member

Comment 7 by, Sep 18 2012

Some copy and paste from an offline chat with Andrew: Although his CL was submitted as r2683, that 
"only landed the ability to enable it...
chrome would have to call this function to enable it as well"
Project Member

Comment 9 by, Feb 13 2013

Blockedon: webrtc:1395
We still may want to re-enable clock drift compensation, but for the 44.1 kHz handling at least, I'm implementing proper resampling in webrtc.
Project Member

Comment 10 by, Aug 21 2014

Labels: -Pri-1 Pri-3
We now support proper resampling from 44.1 kHz when using the float interface. As long as we support the AudioFrame interface this is still a valid issue, but lowering priority to Pri-3 for now.
Project Member

Comment 11 by, Dec 11 2014

Labels: EngTriaged IceBox
Project Member

Comment 12 by, Jun 9 2015

Project Member

Comment 13 by, Jun 10 2015

Project Member

Comment 14 by, Nov 3 2015

Based on the lack of user complaints, I doubt this is still a problem, but it may be worth investigating.
Project Member

Comment 15 by, Nov 3 2015

Issue 366 has been merged into this issue.
Project Member

Comment 16 by, Oct 5 2016

Components: Audio
Project Member

Comment 17 by, Oct 5 2016

Components: -SignalProcessing

Sign in to add a comment