This change includes max_packets_in_buffer and max_delay_ms in the
NetEq config struct. The packet buffer is also no longer limited in
terms of payload sizes (bytes), only number of packets.
The old constants governing the packet buffer limits are deleted.
BUG=3083
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14389004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5989 4adac7df-926f-26a2-2b94-8c16560cd09d
Registeration of iSAC into NetEq is through injecting and external AudioDecoder. This is because iSAC encoder and decoder need to share instances for bandwidth estimator to work. When external decoder is registerred, the sampling rate of the decoder had to be specified. iSAC/48000 decoder has a native sampling rate of 32000 Hz, but it has been registered as 48000 Hz decoder.
This CL fixing this issue by letting NetEq to obtain sampling rate of an external coder according to its existing database.
BUG=3143
TEST=voe_cmd_test,modules_unittest,try-bots
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12139004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5936 4adac7df-926f-26a2-2b94-8c16560cd09d
Adding option to use mock or real objects instead of mocks.
This will help future testing efforts, where each test case can
select whether a mock or a real object should be used.
Adding new test InsertPacketsUntilBufferIsFull.
Removing a few uniteresting mock call warning.
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9839004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5684 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
