New issue
Advanced search Search tips
Starred by 17 users
Status: Assigned
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 Back to list
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