This is the conversation I had with Henrik Lundin regarding this problem.
Me:
In Expand::AnalyseSignal() we compute correlation and distortion, then calculate the ratio of correlation to distortion. There if distortion is zero we expect that correlation to be zero. Although in practice this might be true, I suppose we rarely hit into absolutely periodic signal, but in one of the tests the assertion in line 455 of expand.cc was triggered. The distortion is computed over a shorter length of the signal, while correlation is computed over longer segments. Therefore, I guess, if the signal has just enough zeros at the beginning we can end up in situation that distortion is zero but not the correlation. Do you agree? I didn't have time to attempt to solve this, but if my line of thought is correct, we should not have that assert. Perhaps, if correlation is zero we set the ratio to 0, otherwise, ratio would be the largest value of its own type. Any thoughts?
Henrik:
I agree with you. Go ahead with your solution.
R=minyue@google.com
Review URL: https://webrtc-codereview.appspot.com/1888006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4448 4adac7df-926f-26a2-2b94-8c16560cd09d
Having this failing test being disabled in code will make it
possible to add it on the bots again, and make thus no bot
configuration update needs to be communicated when it's fixed.
BUG=1459
TEST=Compiled with GYP_DEFINES=target_arch=x64 and ran the
test successsfully on Windows. Also ran regular trybots.
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1594004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4164 4adac7df-926f-26a2-2b94-8c16560cd09d
Having this failing test being disabled in code will make it
possible to add it on the bots again, and make thus no bot
configuration update needs to be communicated when it's fixed.
BUG=1458
TEST=Compiled with GYP_DEFINES=target_arch=x64 and ran the
test successsfully on Windows. Also ran regular trybots.
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1593004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4163 4adac7df-926f-26a2-2b94-8c16560cd09d
However, two other "hacks" had to be added to maintain bit-exactness
with legacy.
Note that this change requires a new version of the universal.rtp test
input, although the output reference stays the same.
Moving reference files, and using a new input vector for NetEq4.
The new input vector neteq_universal_new.rtp is identical to the old
neteq_universal.rtp, except that the payload type for CNG packets that
follows a wideband codec is changed to 98.
Update to resources revision 15 where the new reference files are.
Also changing a faulty log error.
Review URL: https://webrtc-codereview.appspot.com/1078009
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3442 4adac7df-926f-26a2-2b94-8c16560cd09d
