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
Background:
In Chrome mirroring which uses 500ms buffering mode,
audio video mismatch happens in the begining because of the lack of the api.
BUG=b/10538425
TEST=pass 'git try' except tests which is aleady broken in the bot. pass 'build/android/test_runner.py gtest -s modules_tests --verbose --release -f *InitialPlayoutDelayTest*'
R=henrika@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2177004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4807 4adac7df-926f-26a2-2b94-8c16560cd09d
First patch set is the same as patch set 3 of http://review.webrtc.org/2237004/
-Make ACM1 to depend on ACM2.
-Remove APIs to set and get background noise mode. There is no VoE call to these
APIs.
-Remove APIs to set and get receive side VAD mode. There is no VoE call to these
APIs, and NetEq 4, doesn't support them.
-Remove callback for in-band DTMF detection. ACM doesn't support in-band DTMF
detection.
-Use acm_common_defs.h everywhere required.
-Complete ACM factory method.
-Update ACMCodecDatabase of ACM2. CNG full-band need to be define-guarded.
Remove dynamic payload-type assignment.
BUG=
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2249004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4785 4adac7df-926f-26a2-2b94-8c16560cd09d
-Make ACM1 to depend on ACM2.
-Remove APIs to set and get background noise mode. There is no VoE call to these APIs.
-Remove APIs to set and get receive side VAD mode. There is no VoE call to these APIs, and NetEq 4, doesn't support them.
-Remove callback for in-band DTMF detection. ACM doesn't support in-band DTMF detection.
-Use acm_common_defs.h everywhere required.
-Complete ACM factory method.
-Update ACMCodecDatabase of ACM2. CNG full-band need to be define-guarded. Remove dynamic payload-type assignment.
BUG=
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2237004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4772 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Tests enabled in r4671 failed:
build.chromium.org/p/client.webrtc/builders/Android%20Tests/builds/31/steps/slave_steps/logs/stdio
> Enable SetInitialPlayoutDelay on Android.
>
> Background:
> In Chrome mirroring which uses 500ms buffering mode,
> audio video mismatch happens in the begining because of the lack of the api.
>
> BUG=b/10538425
> TEST=pass 'git try' except tests which is aleady broken in the bot. pass 'build/android/test_runner.py gtest -s modules_tests --verbose --release -f *InitialPlayoutDelayTest*'
> R=henrika@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/2144004TBR=dwkang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2160006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4672 4adac7df-926f-26a2-2b94-8c16560cd09d
Background:
In Chrome mirroring which uses 500ms buffering mode,
audio video mismatch happens in the begining because of the lack of the api.
BUG=b/10538425
TEST=pass 'git try' except tests which is aleady broken in the bot. pass 'build/android/test_runner.py gtest -s modules_tests --verbose --release -f *InitialPlayoutDelayTest*'
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2144004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4671 4adac7df-926f-26a2-2b94-8c16560cd09d
The ACM tests needed re-writing, because all tests were not individual gtests, and the result was difficult to interpret.
While doing the re-write, I discovered a bug related to 48 kHz CNG. We can't have the 48 kHz CNG active at the moment. The bug is fixed in this CL.
I also needed to rewrite parts of the VAD/DTX implementation, so that the status of VAD and DTX (enabled or not) is propagated back from the function SetVAD().
BUG=issue2173
R=minyue@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1961004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4625 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
