I mistakenly ommitted the checks when logging.h was ported from
libjingle to webrtc. This caused a significant CPU cost for logs which
were later filtered out anyway.
Verified with LS_VERBOSE logging in neteq4, running:
$ out/Release/modules_unittests \
--gtest_filter=NetEqDecodingTest.TestBitExactness \
--gtest_repeat=50 > time.txt
$ grep "case ran" time.txt | grep "[0-9]* ms" -o | sort
Results on a MacBook Retina, averaged over 5 runs:
Verbose logs disabled: 666 ms
Exisiting implementation, verbose logs enabled: 944 ms (1.42x)
New implementation, verbose logs enabled: 673 ms (1.01x)
BUG=2314
R=henrik.lundin@webrtc.org, henrike@webrtc.org, kjellander@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2160005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4682 4adac7df-926f-26a2-2b94-8c16560cd09d
This test goes into an eternal loop sometimes when run under
TSan v2, therefore I'm disabling it until this is resolved.
Doing that, the TSan v2 bot in our new WebRTC FYI waterfall at
http://build.chromium.org/p/client.webrtc.fyi/waterfall
will hopefully go green.
The define used only exists for TSan v2, so v1 should be
unaffected.
The suppression added in http://review.webrtc.org/2126005/
turns out actually has no effect, so I'm removing it again.
It's probably useless since TSan v2 obviously alters the code's
behavior, causing these errors. Since the errors are not TSan v2
failures, the suppression has no effect.
BUG=2259
TEST=test passing locally when run as described in 2259 (since
no tests are run).
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2115005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4639 4adac7df-926f-26a2-2b94-8c16560cd09d
This is a re-land attempt of http://review.webrtc.org/1673004/
It now includes a build/isolate.gypi in WebRTC that includes the same
file as the one that would be included when WebRTC is used in a Chromium
checkout. It is needed since it is not possible to use variables in GYP's
includes sections.
Implemented according to the instructions at
http://www.chromium.org/developers/testing/isolated-testing
Workflow has been like this:
1. create _run GYP target
2. create a stripped down .isolate file
3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
4. runhooks
5. compile
6. test if the test would run (i.e. find it's dependencies) without
actually executing it:
tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
7. If failing, run the fix_test_cases.py script like this:
tools/swarm_client/googletest/fix_test_cases.py --isolated out/Release/testname.isolated
All tests that run on the bots for WebRTC has got _run target
and .isolate file created.
"Normal tests" that run fine on any machine:
* audio_decoder_unittests
* common_audio_unittests
* common_video_unittests
* metrics_unittests
* modules_tests
* modules_unittests
* neteq_unittests
* system_wrappers_unittests
* test_support_unittests
* tools_unittests
* video_engine_core_unittests
* voice_engine_unittests
Tests that requires bare-metal and audio/video devices:
* audio_device_tests
* video_capture_tests
I also added the isolate boilerplate code for the following
tests that are not yet pure gtest binaries (which means they
cannot run isolated yet):
* video_render_tests
* vie_auto_test
* voe_auto_test
TEST=running isolate.py as described above. WebRTC trybots passing. Created a Chromium checkout with third_party/webrtc ToT and this patch applied, passing the runhooks step.
BUG=1916
R=henrike@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2056004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4590 4adac7df-926f-26a2-2b94-8c16560cd09d
As this breaks the FYI bots in
http://build.chromium.org/p/chromium.webrtc.fyi/waterfall
due to different path to isolate.gypi (which cannot easily
be resolved due to limitations in GYP)
> Isolate GYP target and .isolate files for tests
>
> Implemented according to the instructions at
> http://www.chromium.org/developers/testing/isolated-testing
>
> Workflow has been like this:
> 1. create _run GYP target
> 2. create a stripped down .isolate file
> 3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
> 4. runhooks
> 5. compile
> 6. test if the test would run (i.e. find it's dependencies) without
> actually executing it:
> tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
> 7. If failing, run the fix_test_cases.py script like this:
> tools/swarm_client/fix_test_cases.py --isolated out/Release/testname.isolated
>
> All tests that run on the bots for WebRTC has got _run target
> and .isolate file created.
>
> "Normal tests" that run fine on any machine:
> * audio_decoder_unittests
> * common_audio_unittests
> * common_video_unittests
> * metrics_unittests
> * modules_integrationtests
> * modules_unittests
> * neteq_unittests
> * system_wrappers_unittests
> * test_support_unittests
> * tools_unittests
> * video_engine_core_unittests
> * voice_engine_unittests
>
> Tests that requires bare-metal and audio/video devices:
> * audio_device_integrationtests
> * video_capture_integrationtests
>
> I also added the isolate boilerplate code for the following
> tests that are not yet pure gtest binaries (which means they
> cannot run isolated yet):
> * video_render_integrationtests
> * vie_auto_test
> * voe_auto_test
>
> TEST=running isolate.py as described above.
> BUG=1916
> R=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/1673004TBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2040004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4548 4adac7df-926f-26a2-2b94-8c16560cd09d
Implemented according to the instructions at
http://www.chromium.org/developers/testing/isolated-testing
Workflow has been like this:
1. create _run GYP target
2. create a stripped down .isolate file
3. export GYP_DEFINES="$GYP_DEFINES test_isolation_mode=check"
4. runhooks
5. compile
6. test if the test would run (i.e. find it's dependencies) without
actually executing it:
tools/swarm_client/isolate.py run --isolated out/Release/testname.isolated
7. If failing, run the fix_test_cases.py script like this:
tools/swarm_client/fix_test_cases.py --isolated out/Release/testname.isolated
All tests that run on the bots for WebRTC has got _run target
and .isolate file created.
"Normal tests" that run fine on any machine:
* audio_decoder_unittests
* common_audio_unittests
* common_video_unittests
* metrics_unittests
* modules_integrationtests
* modules_unittests
* neteq_unittests
* system_wrappers_unittests
* test_support_unittests
* tools_unittests
* video_engine_core_unittests
* voice_engine_unittests
Tests that requires bare-metal and audio/video devices:
* audio_device_integrationtests
* video_capture_integrationtests
I also added the isolate boilerplate code for the following
tests that are not yet pure gtest binaries (which means they
cannot run isolated yet):
* video_render_integrationtests
* vie_auto_test
* voe_auto_test
TEST=running isolate.py as described above.
BUG=1916
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1673004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4547 4adac7df-926f-26a2-2b94-8c16560cd09d
This inline function is no longer expanded on arm Android, but on x86 Android it
will still be expanded. Move it out-of-line to make things consistent.
This change list will also fix a potential bug on webrtc for Android:
Since the inline function won't be expanded on arm Android,
TickTime::MillisecondTimestamp and Clock::GetRealTimeClock()->TimeInMilliseconds
will be treated as function call, due to macro WEBRTC_CLOCK_TYPE_REALTIME's
guard defined in system_wrappers module they will get current time using
CLOCK_REALTIME.
But on x86 Android, the inline function will be expanded to where it's been
called, if the call happens in other compilation units which don't have
WEBRTC_CLOCK_TYPE_REALTIME definition, it will get current time using
CLOCK_MONOTONIC, while Clock::GetRealTimeClock()->TimeInMilliseconds will always
use CLOCK_REALTIME, then there will be two types of time in x86 Android which
will cause some weird issues like all received remote streams will be dropped
due to future render timestamp.
BUG=None
TEST=WebRTCViEDemo application works well on both arm and x86 Android
R=fischman@webrtc.org, niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1688004
Patch from Jeremy Mao <yujie.mao@intel.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4274 4adac7df-926f-26a2-2b94-8c16560cd09d
A new test target named 'modules_integrationtests' is created
and the following test targets were merged into it:
* audio_coding_module_test
* test_fec
* video_coding_integrationtests
* vp8_integrationtests
A couple of other targets were merged into modules_unittests:
* audio_coding_unittests
* audioproc_unittest
* common_unittests
* video_coding_unittests
* video_processing_unittests
* vp8_unittests
I wasn't able to merge audio_decoder_unittests and neteq_unittests due to
conflicts with different defines in these tests.
Some tests that have special requirements aren't merged into
modules_integrationtests yet. I took the opportunity to rename them
since the bot configs will need to be update anyway:
* audio_device_test_api -> audio_device_integrationtests
* video_capture_module_test -> video_capture_integrationtests
* video_render_module_test -> video_render_integrationtests
Exclude files were added for modules_integrationtests to make sure
the memcheck and tsan bots doesn't tests that are too slow
(audio_coding_module_test and vp8_integrationtests were previously
disabled on those bots).
Suppressions for AudioCodingModuleTest needed to be added to get
modules_integrationtests to pass memcheck (even if the test is
excluded from execution).
BUG=1843
TEST=local execution on Linux and trybots (passing except the merged tests of course)
R=andrew@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1656004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4228 4adac7df-926f-26a2-2b94-8c16560cd09d
* The old resampler was found to have a wraparound bug.
* Remove support for the old resampler from PushResampler.
* Use PushResampler in AudioCodingModule.
* The old resampler must still be removed from the file utility.
BUG=webrtc:1867,webrtc:827
TESTED=unit tests, Chrome using apprtc and voe_cmd_test to verify wrap-around is corrected, voe_cmd_test running through all supported codec sample rates and channels to verify good quality audio
R=henrika@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1590004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4156 4adac7df-926f-26a2-2b94-8c16560cd09d
Note that this means that there is no new code. The code has been taken directly from condition_variable_win.cc/h compensating minimally to be able to split up the two code paths.
Tested by:
1) Disabling native implementation and send to try bots.
2) Only return native implementation (i.e. if native implementation returns NULL there will be a crash when using the condition variable) and send to try bots.
3) The final cl sent to trybots.
All tests pass.
The changes are due to static analyzer code complaints.
BUG=N/A
Review URL: https://webrtc-codereview.appspot.com/1191004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3728 4adac7df-926f-26a2-2b94-8c16560cd09d
This is the first in a series of CLs to bring arbitrary resampling to webrtc.
* Replace Chromium-specific helpers with their respective webrtc versions.
* Add a second constructor to permit runtime selection of block_size.
* Add stringize_macros to system_wrappers.
BUG=webrtc:1395
TESTED=unit tests
Review URL: https://webrtc-codereview.appspot.com/1097012
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3518 4adac7df-926f-26a2-2b94-8c16560cd09d
pthread_t is a pointer type on Mac OS X, and is thus 32 bits wide in the
32-bit environment and 64 bits wide in the 64-bit environment. WebRTC's
thread ID routines assume that thread IDs can always fit inside a uint32_t,
but this is not the case in the 64-bit Mac environment when using pthread_t
as the basis for a thread ID. Instead, switch to using the underlying Mach
port for the thread, which is a 32-bit quantity in both the 32-bit and 64-bit
environments.
The only place this seems to be used is in TraceImpl::AddThreadId, and it's
only used there for a thread ID for display.
This is a better fix than https://webrtc-codereview.appspot.com/929015 .
Review URL: https://webrtc-codereview.appspot.com/1063005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3427 4adac7df-926f-26a2-2b94-8c16560cd09d
