Flakiness was caused by a race condition between two atomic integers shared by two threads. Fixed by counting bad packets (those not containing the expected extension) instead of the good packets.
The CL also eliminates another possible flake by introducing a test fixture which doesn't automatically start sending audio packets when constructed.
BUG=3340,3356
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14499004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6182 4adac7df-926f-26a2-2b94-8c16560cd09d
With the switch recipes on the buildbots and the deprecation of
the custom script at
https://code.google.com/p/webrtc/source/browse/trunk/webrtc/test/buildbot_tests.py
these tests will start failing when Chromium's runtest.py is passing
--brave-new-test-launcher --test-launcher-bot-mode
to the test.
A similar change was made for most of WebRTC's tests (that depends on
the test_support_main target) in
https://webrtc-codereview.appspot.com/2222005
BUG=chromium:346198
TEST=Successfully launched the executables on Linux and Mac using:
out/Release/voe_auto_test --brave-new-test-launcher --test-launcher-bot-mode --automated --test-launcher-summary-output=/tmp/tmpwhx6Zz
out/Release/vie_auto_test --brave-new-test-launcher --test-launcher-bot-mode --automated --capture_test_ensure_resolution_alignment_in_capture_device=false --test-launcher-summary-output=/tmp/tmpwhx6Zz
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13499004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6135 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add ability to VoE to send Absolute Sender Time header extension.
- Refactor handling of RTP header extensions in VoE to work the same as in ViE.
- Add API to enable receiving Absolute Sender Time in VoE.
This is part of the work to include audio packets in bandwidth estimation, for
better accuracy in estimates.
BUG=
TBR=solenberg@webrtc.org,henrikg@webrtc.org,stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5654 4adac7df-926f-26a2-2b94-8c16560cd09d
Reasons for removing:
- Feels like a complete hack IMHO.
- Not used by any client.
- Unclear functionality regarding time stamp, marker bit etc.
- Causes several issues in tests due to a bad design which mainly depends on the fact that this API "breaks" an ongoing data/packet flow and it complicates the threading model and creates risks for deadlock and memory corruption. Not worth trying to fix given the very unclear benefit of maintaining the API. Better to remove the API instead.
- We also see lots of TSan races and memcheck errors related to this API.
BUG=2296,2240
R=mflodman@webrtc.org, niklas.enbom@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8819004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5574 4adac7df-926f-26a2-2b94-8c16560cd09d
These high level tests were disabled over time. Since they depend on
real-time results and the filesystem, they tended to be flaky on the
bots. We now give it a very generous 1 second to start up all channels
before verification and a further relaxed file length check. If we
continue to see problems, I will up the startup delay.
The restored tests would have caught the AGC bug fixed here:
https://code.google.com/p/webrtc/source/detail?r=5454
Add a new "real audio" stress test to exercise more code paths. This
would have caught the refactor bug fixed here:
https://code.google.com/p/webrtc/source/detail?r=5437
BUG=2164,2844
TESTED=git try. Verified it would have caught the aforementioned bugs
by reintroducing them.
R=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8009004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5522 4adac7df-926f-26a2-2b94-8c16560cd09d
This will allow an embedder to use it directly.
Adding inertia/hangover time between updates of the reported detection status to the algorithm, controlled by a parameter. That is usually desired and this way a consumer of
the class don't have to implement that. (VoiceEngine will let it be 1, which results in the same behavior as before, and keep controlling the hangover itself.)
R=andrew@webrtc.org, niklas.enbom@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6219004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5462 4adac7df-926f-26a2-2b94-8c16560cd09d
Add a flag --log_file which produces the existing behaviour of dumping
logs of all severities to a file. By default, warnings and errors will
now be output to stderr. This is generally more useful for the testing
done with voe_cmd_test.
TESTED=logs output to stderr by default and to the usual file when the
flag is specified.
R=tnakamura@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6849005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5409 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL fixes the problem with voe_auto_test extended-codec test, as well as
extended-file test. First problem was that Opus was not added as a special case, like the other codecs, and the second problem was that the tests were not updated when test files were moved to the resources catalogue.
There are still some tests that fails. Here is a list of all extended tests and their status:
Base: fails - the reason seem to be that external transport has been removed.
CallReport: passes
Codec: passes (with this CL)
DTMF: passes
Encryption: fails or is dissabled?
VoEExternalMedia: passes
File: passes (with this CL)
Hardware: passes
NetEqStats: empty?
Network: passes
RTP_RTCP: fails
VideoSync: fails
VolumeControl: passes
BUG=issue2234
R=andrew@webrtc.org, henrika@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2023004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5020 4adac7df-926f-26a2-2b94-8c16560cd09d
This version of LoopBackTransport hands packets over to a network thread
which will deliver them instead. This allows SendRTP and SendRTCP to
always be able to return, preventing deadlocks in voe_auto_test. The
previous case did not represent actual network usage. Now the send and
receive side can run concurrently with the receiving side. Previously
the sender thread also drove the receiving side, which does not
represent the regular use case where packets are put on a network
socket.
BUG=1568,2081,2178
TEST=Ran VoiceEngine RtpRtcpTest.*, known for deadlocking, 100+ times.
R=xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1985005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4516 4adac7df-926f-26a2-2b94-8c16560cd09d
The complexity of the last ChannelManager and potentially usage of it as well caused race conditions and deadlocks in loopback voe_auto_test. This ref-counted solution takes no long-term locks, uses less locks overall and is significantly easier to understand.
ScopedChannel has been split up into a ChannelOwner with a reference to a channel and an Iterator over ChannelManager. Previous code was really used for both things. ChannelOwner is used as a shared pointer to a channel object, while an Iterator should work as expected.
BUG=2081
R=tommi@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1802004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4502 4adac7df-926f-26a2-2b94-8c16560cd09d
