Ask the OS for the mic volume every 1 second rather than with every 10
ms chunk. The previous behavior was consuming ~2% of the CPU load of
a voice engine call, and is now negligible.
This is consistent with the webrtc Windows Core Audio implementation,
as well as the Chromium Mac implementation:
https://code.google.com/p/chromium/codesearch#chromium/src/media/audio/agc_audio_stream.h
TEST=voe_cmd_test with AGC continues to work well on Mac.
Review URL: https://codereview.webrtc.org/1564223002
Cr-Commit-Position: refs/heads/master@{#11182}
* Move PlatformThread to rtc::.
* Remove ::CreateThread factory method.
* Make non-scoped_ptr from a lot of invocations.
* Make Start/Stop void.
* Remove rtc::Thread priorities, which were unused and would collide.
* Add ::IsRunning() to PlatformThread.
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1476453002 .
Cr-Commit-Position: refs/heads/master@{#10812}
Also removes all virtual methods. Permits using a thread from
rtc_base_approved (namely event tracing).
BUG=webrtc:5158
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1469013002
Cr-Commit-Position: refs/heads/master@{#10760}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
The class doesn't do anything in almost all cases except for grabbing and releasing locks + allocate memory. There are a couple of methods there such as WaitForKey and GetTimeInMs that are used, but those methods aren't specific to audio and we have implementations of these elsewhere. The third method, StringCompare isn't used anywhere (and also isn't specific to audio).
BUG=
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50009004
Cr-Commit-Position: refs/heads/master@{#9220}
So in the HandleStreamFormatChange() callback, we need to re-initiate the playout as same as what we do in InitPlayout(). Here we merely copy those codes out from InitPlayout() into a new SetDesiredPlayoutFormat() function for the invoking from the two places.
Previously, HandleStreamFormatChange only re-creates the AudioConverter, which is not enough. We also need to reset the buffer size and refresh the latency.
BUG=4240
TEST=Manual Test
R=andrew@webrtc.org, henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36029004
Cr-Commit-Position: refs/heads/master@{#8815}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8815 4adac7df-926f-26a2-2b94-8c16560cd09d
Removes ThreadPosix::InitParams and a corresponding wait for an event.
This unblocks ThreadPosix::Start which had to wait for thread scheduling
for an event to trigger on the spawned thread, giving faster Start()
calls.
BUG=4413
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43699004
Cr-Commit-Position: refs/heads/master@{#8709}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8709 4adac7df-926f-26a2-2b94-8c16560cd09d
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
The addition of logging.h in r4729 was causing the win trybot to fail
with "#pragma deprecated" errors in standard library headers. This
turned out to be due to including strsafe.h (via audio_device_config.h)
before sstream (via logging.h).
strsafe.h was only being included for the unused DEBUG_PRINT macro. I
removed all references to it.
This incidentally removes a bunch of other unneeded headers discovered
while trying to track the problem down.
This didn't show up in the commitbots; my guess is that the trybots are
using the VC10 toolchain and the commitbots the VC11 toolchain.
TBR=pbos
Review URL: https://webrtc-codereview.appspot.com/2204004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4738 4adac7df-926f-26a2-2b94-8c16560cd09d
Does not increase memory requirements. Adds an additional check to ensure
configurations requiring more memory per IO block than the input ring buffer
contains are rejected.
BUG=1904
TESTED=Using Soundflower (64 channels) at 48 kHz as input gives good quality.
Selecting a higher sample rate (96 kHz), which would otherwise give choppy
audio, instead results in an error.
R=henrika@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1628004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4198 4adac7df-926f-26a2-2b94-8c16560cd09d
