GetRTT() was separated from GetRTPStatistics() but the warnings were not updated.
Now GetRTT() is only only used by GetRTPStatistics() and the warning pops up pointlessly and too often.
This CL is to suppress these warnings and maintain a proper warning for GetRTPStatistics().
BUG=
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36469004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7899 4adac7df-926f-26a2-2b94-8c16560cd09d
This also marks all virtual overrides of other classes in the same files.
This will make a subsequent change I intend to do safer, where I'll change the
argument types of the base Transport functions, by breaking the compile if I
miss any overrides.
This also highlighted a number of unused functions. I've removed some of these.
TBR=mflodman@webrtc.org, pkasting@chromium.org
BUG=none
TEST=none
Review URL: https://webrtc-codereview.appspot.com/28709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7421 4adac7df-926f-26a2-2b94-8c16560cd09d
RemoteNtpTimeEstimator needed user to give a remote SSRC and it intended to call RtpRtcp module to obtain RTT, to be able to calculate Ntp time.
When RTT cannot be directly obtained from the RtpRtcp module with the specified SSRC, RemoteNtpTimeEstimator would fail.
This change allows RemoteNtpTimeEstimator to calculate NTP with an external RTT estimate.
An immediate benefit is that capture_start_ntp_time_ms_ can be obtained in a Google hangout call.
BUG=
TEST=chromium + hangout call
R=stefan@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24879004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7407 4adac7df-926f-26a2-2b94-8c16560cd09d
An error reported while retreiving playout timestamp if no RTP packet received, yet. This causes an overflow of errors/warnings in applications where few channel are created but only one is actively engaged in a conversation. Therefore, we don't find such logging informative (there is no check upon correctness of timestamp computaion only if a packet already received).
BUG=3545
TEST=manual with voe_cmd_test,try bots
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18869004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6781 4adac7df-926f-26a2-2b94-8c16560cd09d
---
Fixes for re-enabling more MSVC level 4 warnings: webrtc/ edition
This contains fixes for the following sorts of issues:
* Possibly-uninitialized local variable
* Signedness mismatch
* Assignment inside conditional
This also contains a small number of other cleanups to nearby code. In
particular several warning-disables for MSVC are removed because they don't seem
to be necessary (either that warning is not enabled or the code does not trigger
it).
BUG=crbug.com/81439
TEST=none
R=henrika@webrtc.org, pkasting@chromium.org
Review URL: https://webrtc-codereview.appspot.com/18769004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6667 4adac7df-926f-26a2-2b94-8c16560cd09d
* In AudioCodingModuleImpl::PlayoutData10Ms, don't reset the timestamp got from GetAudio.
* When there're more than one participant, set AudioFrame's RTP timestamp to 0.
* Copy ntp_time_ms_ in AudioFrame::CopyFrom method.
* In RemixAndResample, pass src frame's timestamp_ and ntp_time_ms_ to the dst frame.
* Fix how |elapsed_time_ms| is computed in channel.cc by adding GetPlayoutFrequency.
Tweaks on ntp_time_ms_:
* Init ntp_time_ms_ to -1 in AudioFrame ctor.
* When there're more than one participant, set AudioFrame's ntp_time_ms_ to an invalid value. I.e. we don't support ntp_time_ms_ in multiple participants case before the mixing is moved to chrome.
Added elapsed_time_ms to AudioFrame and pass it to chrome, where we don't have the information about the rtp timestmp's sample rate, i.e. can't convert rtp timestamp to ms.
BUG=3111
R=henrik.lundin@webrtc.org, turaj@webrtc.org, xians@webrtc.org
TBR=andrew
andrew to take another look on audio_conference_mixer_impl.cc
Review URL: https://webrtc-codereview.appspot.com/14559004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6346 4adac7df-926f-26a2-2b94-8c16560cd09d
We want to remove energy_ entirely as we've seen that carrying around
this potentially invalid value is dangerous.
Results in the removal of AudioBuffer::is_muted(). This wasn't used in
practice any longer, after the level calculation moved directly to
channel.cc
Instead, now use ProcessMuted() in channel.cc, to shortcut the level
computation when the signal is muted.
BUG=3315
TESTED=Muting the channel in voe_cmd_test results in rms=127.
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6159 4adac7df-926f-26a2-2b94-8c16560cd09d
Break out the computation to a separate class, and call directly into
this from channel.cc rather than going through AudioProcessing. This
circumvents AudioProcessing's sample rate limitations.
We now compute the RMS over all samples rather than downmixing to a
single channel. This makes the call point in channel.cc easier, is
more "correct" and should have similar (negligible) complexity.
This caused slight changes in the RMS output, so the ApmTest.Process
reference has been updated. Snippet of the failing output:
[ RUN ] ApmTest.Process
Running test 4 of 12...
Value of: rms_level
Actual: 27
Expected: test->rms_level()
Which is: 28
Running test 5 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 6 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 10 of 12...
Value of: rms_level
Actual: 27
Expected: test->rms_level()
Which is: 28
Running test 11 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
Running test 12 of 12...
Value of: rms_level
Actual: 26
Expected: test->rms_level()
Which is: 27
BUG=3290
TESTED=Chrome assert is avoided and both voe_cmd_test and apprtc
produce reasonable printed out results from RMS().
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16459004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6056 4adac7df-926f-26a2-2b94-8c16560cd09d
Replace the two versions with a single DownConvertToCodecFormat. As
mentioned in comments, this could be further consolidated with
RemixAndResample but we should write a full audio converter class in
that case.
Along the way:
- Fix the bug present in Channel::Demultiplex with mono input and a
stereo codec.
- Remove the 32 kHz max from the OnDataAvailable path. This avoids a
48 -> 32 -> 48 conversion when VoE is passed 48 kHz audio; instead we
get a straight pass-through to ACM. The 32 kHz conversion is still
needed in the RecordedDataIsAvailable path until APM natively supports
48 kHz.
- Merge resampler improvements from ACM1 to ACM2. This allows ACM to
handle 44.1 kHz audio passed to VoE and was originally done here:
https://webrtc-codereview.appspot.com/1590004
- Reuse the RemixAndResample unit tests for DownConvertToCodecFormat.
- Remove unused functions from utility.cc.
BUG=3155,3000,b/12867572
TESTED=voe_cmd_test using both the OnDataAvailable and
RecordedDataIsAvailable paths, with a captured audio format of all
combinations of {44.1,48} kHz and {1,2} channels, running through all
codecs, and finally using both ACM1 and ACM2.
R=henrika@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11019005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5843 4adac7df-926f-26a2-2b94-8c16560cd09d
In the case where a network glitch causes a packet to arrive so late
that the jitter buffer has gone into expand mode, the playout timestamp
could have been increased to a value that is larger than the RTP
timestamp of the late packet when it finally arrives. This causes
the difference to be negative, and would make the value wrap (unsigned).
With this fix, the difference is set to zero when the playout
timestamp is ahead of the incoming RTP timestamp. Further down in the
method, a zero-value will lead to the averaging filter not being updated.
BUG=3080
R=henrika@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10199004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5735 4adac7df-926f-26a2-2b94-8c16560cd09d
