The performance test is based on the neteq4_speed_test application. The
bulk of the test code is extracted into a test class, and included into
the neteq_unittest_tools target. The actual gtest that runs the
performance test is implemented in neteq_performance_unittest.cc, and
built as a part of webrtc_perf_tests.
The old stand-alone test application is now made dependent on the new
test class, to avoid code duplication.
BUG=2397
R=andrew@webrtc.org, kjellander@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5362 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead have ProcessStream transparently handle changes to the stream
audio parameters (sample rate and channels). This removes two locks
per 10 ms ProcessStream call taken by VoiceEngine (four total with the
audio level indicator.)
Also, prepare future improvements by having the splitting filter take
a length parameter. This will allow it to work at different sample
rates. Remove the useless splitting_filter wrapper.
TESTED=voe_cmd_test with audio processing enabled and switching between
codecs; unit tests.
R=aluebs@webrtc.org, bjornv@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3949004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5346 4adac7df-926f-26a2-2b94-8c16560cd09d
The new version of Opus doesn't generate the same number of bytes encoding the test vectors in audio_decoder_unittest. Therefore the test was updated not to check the length of the encoded packet, to prepare for the coming roll of Opus. Same change was applied to iSAC, which can also generate different number of bytes on different platforms.
BUG=1459
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/4609004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5195 4adac7df-926f-26a2-2b94-8c16560cd09d
Wrap-arounds in sequence numbers (and in timestamps) were not always
treated correctly. This is fixed by introducing two helper functions
for correct comparisons, and by casting to the right word size.
Also added a new member variable to AutomodeInst_t. The new member keeps
track of when the first packet has been registered in the automode code.
This was previously done implicitly (and not very good) using the fact
that the lastSeqNo and lastTimestamp members were initialized to zero.
Two new unit tests were added as part of this CL.
NetEqDecodingTest.SequenceNumberWrap was failing before the fixes were
made; now it is ok.
BUG=2654
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/4139004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5150 4adac7df-926f-26a2-2b94-8c16560cd09d
The current implementation using std::vector is too slow.
This CL introduces a new implementation, using a regular
array as data container.
In AudioMultiVector::ReadInterleavedFromIndex, a special case for
1 channel was implemented, to further reduce runtime. Finally,
AudioMultiVector::Channels was reimplemented.
The changes in this CL reduces the runtime of neteq4_speed_test
by 33%.
BUG=1363
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5115 4adac7df-926f-26a2-2b94-8c16560cd09d
Analogous to the recent libjingle change: http://cl/54929753-p10.
This supports scoped_ptr<T[]> and scoped_ptr<C, FreeDeleter> rather
than scoped_array and scoped_ptr_malloc respectively.
- Add Chromium's template-based COMPILE_ASSERT. We didn't have this
previously in order to support the macro in C. Instead, move the
existing macro to compile_assert_c.h.
- Additionally copy the move.h and template_util.h depedencies and add
the WARN_UNUSED_RESULT macro.
- Leave scoped_array and scoped_ptr_malloc for now, but mark as
deprecated.
- Remove scoped_ptr foo(NULL) use. The default constructor handles it.
- Remove the now redundant COMPILE_ASSERT from peerconnection_jni.cc.
- Add a CHECK_ARRAY_SIZE macro to rtp_format_vp8_unittest.cc to remove
some repeated code.
TESTED=trybots
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2449005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5015 4adac7df-926f-26a2-2b94-8c16560cd09d
Recent changes in GYP seem to have broken our previous
"hack" for getting the GYP rule for .isolate files
imported from the Chromium build/isolate.gypi.
The best solution for now is to remove the hack
and check in a copy of Chromium's src/build/isolate.gypi
in WebRTC's build/ dir instead. A similar approach is
used for our build/protoc.gypi file.
TEST=On Linux, I successfully ran:
gclient runhooks
ninja -C out/Release
and verified a bunch of .isolated files were created in
out/Release (which didn't happen before this patch).
I also renamed the build/isolate.gypi from Chromium to
ensure that our own is used and not that one (in case any
paths would be incorrect).
I also ran build/gyp_chromium in a Chromium checkout
with WebRTC in third_party/webrtc having this patch applied
to ensure GYP processing was still working.
Finally, I verified that the same project generation and
compilation from a Chromium checkout worked the way we build
our Android native tests, using:
. build/android/envsetup.sh
GYP_DEFINES="$GYP_DEFINES include_tests=1 enable_tracing=1" gclient runhooks
ninja -C out/Release android_builder_webrtc
BUG=1916
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2338004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4907 4adac7df-926f-26a2-2b94-8c16560cd09d
We encounter a sample-underrun if NetEq is initialized with a sampling rate fs =16000 and receive Opus packets with frame-size less than 5 ms. The reason is as follows.
Let say NetEq buffer has 4 packets of Opus each of size 2.5ms this means that internally timestamp of packets incremented by 80 (internally Opus treated as 32 kHz codec). Given the initial sampling rate of NetEq, at the first time that it wants to fetch packets, it targets to fetch 160 samples. Therefore, it will only extracts 2 packets. Decoding these packets give us exactly 160 samples (5 ms at 32 kHz), however, upon decoding the first packet the internal sampling rate will be updated to 32 kHz. So it is expected that sync buffer to deliver 320 samples while it does only have 160 samples (or maybe few more as it starts with some zeros). And we encounter and under-run.
Even if we ignore the under-run "assert(sync_buffer_->FutureLength() >= expand_->overlap_length())" (neteq_impl.cc::811) is trigered. I'm not sure what happens if we remove this assert perhaps NetEq will work fine in subsequent calls. However the first under-run is blocking ACM2 test to pass.
Here I have a solution to update sample rate as soon as a packet is inserted, if required. It not a very efficient approach as we do the same reset in NetEqImpl::Decode().
It is a bit tricky to reproduce this because the TOT ACM tests do not run ACM2. In https://webrtc-codereview.appspot.com/2192005/ I have a patch to run both ACMs. To reproduce the problem, one can patch that CL and run
$ out/Debug/modules_tests --gtest_filter=AudioCodingModuleTest.TestOpus
Note that we would not encounter any problem if NetEq4 is initiated with 32000 Hz sampling rate. You can test this by setting |kNeteqInitSampleRateHz| to 32000 in webrtc/modules/audio_coding/main/acm2/acm_receiver.cc
BUG=
R=andrew@webrtc.org, henrik.lundin@webrtc.org, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2306004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4896 4adac7df-926f-26a2-2b94-8c16560cd09d
If there is audio in a codec's audio buffer and sample-rate or number of channels change the audio buffer has to reset. Otherwise, the amount of audio in the buffer is misinterpreted any syncronization between 10ms audio blocks and their associated timestamps is lost.
For instance, assume changing from stereo to mono when there is 10ms stereo in the buffer. The "new" codec will interpret this as 20 ms audio, therefore, 2 blocks of 10 ms, but there is only one timestamp. This will results in ACMGenericCodec::in_timestamp_ix_write_ updated to a negative number after an encode is performed.
The drawback with this solution is that if packet-size of the codec is changed then audio buffer is reset wich is not necessary. We accept this as it is a rare case in practice that clients of ACM re-register send codecs to change packet-size.
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2151006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4887 4adac7df-926f-26a2-2b94-8c16560cd09d
