This is the same change as already made for Windows:
https://webrtc-codereview.appspot.com/37069004/
* Remove "dead" and "alive" variables.
* Remove critical section
* Remove implementation of SetNotAlive()
* Always set thread name
* Add thread checks for correct usage.
* Changed AudioDeviceMac to create/start/stop/delete thread objects for playout and recording, inside the respective start and stop method. The reason for this is because the AudioDeviceMac instance is currently being created on one thread and the above Start/Stop methods are being called on a different thread. So, my change makes creation, start/stop, deletion of the thread objects always happen on the same thread.
I'm making CurrentThreadId() in rtc_base_approved more visible so that it can be used from there instead of inside webrtc. Down the line we will have more thread concepts in rtc_base_approved, so I put a TODO for myself to move this functionality to there once we do.
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40599004
Cr-Commit-Position: refs/heads/master@{#8235}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8235 4adac7df-926f-26a2-2b94-8c16560cd09d
To more easily determine if for example the AEC is not working properly one could monitor how often the estimated delay is out of bounds. With out of bounds we mean either being negative or too large, where both cases will break the AEC.
A new delay metric is added telling the user how often poor delay values were estimated. This is measured in percentage since last time the metrics were calculated.
All APIs have been updated with a third parameter with EchoCancellation::GetDelayMetrics() giving the option to exclude the new metric not to break existing code.
The new metric has been added to audio_processing_unittests with an additional protobuf member, and reference files accordingly updated.
voe_auto_test has not been updated to display the new metric.
BUG=4246
TESTED=audioproc on files
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39739004
Cr-Commit-Position: refs/heads/master@{#8230}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8230 4adac7df-926f-26a2-2b94-8c16560cd09d
The surrounding similar methods all used unsigned char, using unsigned int in
this case looks like an accident, especially since the function passes on the
value in question to a function expecting a uint8.
BUG=none
TEST=none
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40529004
Cr-Commit-Position: refs/heads/master@{#8228}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8228 4adac7df-926f-26a2-2b94-8c16560cd09d
* Remove "dead" and "alive" variables.
* Remove critical section
* Skip synchronizing with the worker thread to verify startup (no need).
* Remove implementation of SetNotAlive()
* Always set thread name
* Add thread checks for correct usage.
Also added some TODOs for myself for the ThreadWrapper interface.
I'm removing the HasNoMonitorThread test since it is no longer relevant and ends up checking the wrong thing (ProcessThread - a generic thread type) in the wrong way (parsing a debug log) :) I think it served a purpose some years ago, but things have changed since.
BUG=2902
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37069004
Cr-Commit-Position: refs/heads/master@{#8220}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8220 4adac7df-926f-26a2-2b94-8c16560cd09d
For build_with_chromium==1 the includes will be the same.
For build_with_chromium==0 the <(DEPTH) variable is replaced by ../..
which should be the same in all common use cases.
This change makes the include paths for all GYP targets
more similar to the setup in the
direct_dependent_settings section further down.
BUG=4185
TESTED=Trybots + build in Chromium with third_party/webrtc patched with this CL.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41739004
Cr-Commit-Position: refs/heads/master@{#8219}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8219 4adac7df-926f-26a2-2b94-8c16560cd09d
Broke tests in Chrome for some reason:
[ RUN ] WebRtcAecDumpBrowserTest.CallWithAecDump
[80131:1287:0129/074432:30561723987517:ERROR:vt_video_decode_accelerator.cc(132)] Failed to create VTDecompressionSession: codecOpenErr (-8973)
[80129:1287:0129/074432:30562276677373:INFO:CONSOLE(64)] "Looking at video in element remote-view-1", source: http://127.0.0.1:61401/media/webrtc_test_utilities.js (64)
[80129:1287:0129/074432:30562281435788:INFO:CONSOLE(64)] "Looking at video in element remote-view-2", source: http://127.0.0.1:61401/media/webrtc_test_utilities.js (64)
[80129:1287:0129/074432:30562315329399:INFO:CONSOLE(800)] "Negotiating call...", source: http://127.0.0.1:61401/media/peerconnection-call.html (800)
[80133:29187:0129/074432:30562402039578:FATAL:overuse_frame_detector.cc(388)] Check failed: processing_thread_.CalledOnValidThread().
0 libbase.dylib 0x000000010dfd688f base::debug::StackTrace::StackTrace() + 47
1 libbase.dylib 0x000000010dfd68e3 base::debug::StackTrace::StackTrace() + 35
2 libbase.dylib 0x000000010e030076 logging::LogMessage::~LogMessage() + 70
3 libbase.dylib 0x000000010e02f0c3 logging::LogMessage::~LogMessage() + 35
4 libcontent.dylib 0x000000011d8c0cd5 webrtc::OveruseFrameDetector::TimeUntilNextProcess() + 245
5 libcontent.dylib 0x000000011d31ddfd webrtc::ProcessThreadImpl::Process() + 525
6 libcontent.dylib 0x000000011d31d836 webrtc::ProcessThreadImpl::Run(void*) + 38
7 libcontent.dylib 0x000000011d10c390 webrtc::ThreadPosix::Run() + 288
8 libcontent.dylib 0x000000011d10c076 webrtc::StartThread(void*) + 38
9 libsystem_pthread.dylib 0x00007fff8e667899 _pthread_body + 138
10 libsystem_pthread.dylib 0x00007fff8e66772a _pthread_struct_init + 0
11 libsystem_pthread.dylib 0x00007fff8e66bfc9 thread_start + 13
> Reducing locking in OveruseFrameDetector and increasing constness.
>
> I also added a few TODOs there to see what we can do to reduce the chance of contention.
> To catch regressions, I've started using the ThreadChecker class on the processing thread but it might also be a good idea to add similar checks for other known threads such as the thread we receive frames on. I'm sure we can reduce locking even further.
>
> BUG=2822
> R=asapersson@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/33129004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34079004
Cr-Commit-Position: refs/heads/master@{#8206}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8206 4adac7df-926f-26a2-2b94-8c16560cd09d
Changes differing from https://webrtc-codereview.appspot.com/37859004:
* I put the include_tests==1 stuff of audio_coding.gypi in its
own audio_coding_tests.gypi file, including the Android and isolate
targets which were incorrectly located in the previous CL
* I moved the bwe utilities in remote_bitrate_estimator.gypi
into include_tests==1 since they depend on test.gyp after I
cleaned up the duplicated inclusion of rtp_file_reader.cc
R=stefan@webrtc.orgTBR=tina.legrand@webrtc.org
TESTED=Passing gyp and compile using:
webrtc/build/gyp_webrtc -Dinclude_tests=1
webrtc/build/gyp_webrtc -Dinclude_tests=0
I also setup a Chromium checkout with my checkout mounted in
third_party/webrtc and ran build/gyp_chromium successfully.
BUG=4185
Review URL: https://webrtc-codereview.appspot.com/33159004
Cr-Commit-Position: refs/heads/master@{#8205}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8205 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add max_bit_rate and max_payload_size_bytes to config structs.
- Fix support for 48 kHz sample rate.
- Fix iSAC-RED.
- Add method UpdateDecoderSampleRate().
- Update locking structure with a separate lock for local member
variables used by the encoder methods.
BUG=3926
COAUTHOR:kwiberg@webrtc.org
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41659004
Cr-Commit-Position: refs/heads/master@{#8204}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8204 4adac7df-926f-26a2-2b94-8c16560cd09d
I also added a few TODOs there to see what we can do to reduce the chance of contention.
To catch regressions, I've started using the ThreadChecker class on the processing thread but it might also be a good idea to add similar checks for other known threads such as the thread we receive frames on. I'm sure we can reduce locking even further.
BUG=2822
R=asapersson@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33129004
Cr-Commit-Position: refs/heads/master@{#8203}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8203 4adac7df-926f-26a2-2b94-8c16560cd09d
This fixes a two year old TODO of deleting dead code :)
In cases where the _id or id_ member variable is being used for tracing,
I changed the member to at least be const.
It doesn't look like id's are that useful anymore so maybe the next step is to get rid of them.
BUG=
R=henrika@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37849004
Cr-Commit-Position: refs/heads/master@{#8201}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8201 4adac7df-926f-26a2-2b94-8c16560cd09d
This required to move the AGC tools source files
into webrtc/tools and create a new agc_test_utils target.
Since audio_codec_speed_tests.gypi referenced sources above,
the best approach I could come up with was to add an audio_coding.gypi
file at a higher level and move the targets in there (+ the includes from
modules.gyp which is an improvement IMO).
I also added a PRESUBMIT.py check to prevent new source
entries being added with <(webrtc_root) in the path.
BUG=4185
R=andrew@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37859004
Cr-Commit-Position: refs/heads/master@{#8197}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8197 4adac7df-926f-26a2-2b94-8c16560cd09d
The latter file was more up-to-date. The files are now identical
with the following exceptions:
* The namespace used (rtc vs. webrtc).
* The name of the include guard.
* base/scoped_ptr.h still has two extra methods, accept() and use().
* base/scoped_ptr.h still includes webrtc/base/common.h even though
it doesn't need it itself, since several .cc files expect to get
it for free by incuding base/scoped_ptr.h. This is of course bad
manners, and the "unused" include will be removed in a future CL.
A later CL will remove system_wrappers/interface/scoped_ptr.h.
R=andrew@webrtc.org
Committed: https://code.google.com/p/webrtc/source/detail?r=8147
And reverted again, because out-of-tree code using this file was defining nullptr to 0: https://code.google.com/p/webrtc/source/detail?r=8149
Review URL: https://webrtc-codereview.appspot.com/36919004
Cr-Commit-Position: refs/heads/master@{#8196}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8196 4adac7df-926f-26a2-2b94-8c16560cd09d
When using the paced sender, packets will be put into the rtp packet
history and then retreived from there again when it is time to send.
In some cases (low send bitrate and very large frames created) this
may overflow, causing packets to be overwritten in the packet history
before they have been sent.
Check this condition and expand history size if needed.
This is primarily triggered during screenshare, when
switching to a large picture with lots of high frequency
details in it.
BUG=4171
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34879004
Cr-Commit-Position: refs/heads/master@{#8195}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8195 4adac7df-926f-26a2-2b94-8c16560cd09d
