BUG=4690
Changes:
1. In MediaEngineInterface changed CreateChannel() to CreateChannel(const AudioOptions&). Plan is to eventually remove Get/SetAudioOptions and the cousins SetDelayOffset and SetDevices.
2. In ChannelManager changed CreateVoiceChannel(...) to CreateVoiceChannel(..., const AudioOptions&).
3. In ChannelManager removed SetEngineAudioOptions, because it is not used and we want to eventually remove SetAudioOptions.
4. Updated MediaEngineInterface implementations and unit tests accordingly.
5. In WebRtcVoiceEngine changed access of Set/ClearOptionOverrides to protected. These are only used by WebRtcVoiceMediaChannel (now a friend). Plan is to rethink the logic behind option overrides.
6. Cosmetics: replaced NULL with nullptr in touched code
R=solenberg@google.com, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/56499004
Cr-Commit-Position: refs/heads/master@{#9330}
It looks like it is being used single threadedly, except that in some cases it is created and/or destroyed in threads other than the one running its operations. As such, CaptureManager() contains 'thread_checker_.DetachFromThread()' and ~CaptureManager() does not have a DCHECK.
BUG=
R=perkj@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36279004
Cr-Commit-Position: refs/heads/master@{#8498}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8498 4adac7df-926f-26a2-2b94-8c16560cd09d
This is a big refactoring of the existing C++/JNI/Java support for audio recording in native WebRTC:
- Removes unused code and old WEBRTC logging macros
- Now uses optimal sample rate and buffer size in Java AudioRecord (used hard-coded sample rate before)
- Makes code more inline with the implementation in Chrome
- Adds helper methods for JNI handling to improve readability
- Changes the threading model (high-prio audio thread now lives in Java-land and C++ only works as proxy)
- Adds basic thread checks
- Removes all locks in C++ land
- Removes all locks in Java
- Improves construction/destruction
- Additional cleanup
Tested using AppRTCDemo and WebRTCDemo APKs on N6, N5, N7, Samsung Galaxy S4 and
Samsung Galaxy S4 mini (which uses 44.1kHz as native sample rate).
BUG=NONE
R=magjed@webrtc.org, perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33969004
Cr-Commit-Position: refs/heads/master@{#8325}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8325 4adac7df-926f-26a2-2b94-8c16560cd09d
Previously if thread A->Send is called on thread B, B->ReceiveSends will be called, which enables an arbitrary thread to invoke calls on B while B is wait for A->Send to return. This caused mutliple problems like issue 3559, 3579.
The fix is to limit B->ReceiveSends to only process requests from A.
Also disallow the worker thread invoking other threads.
BUG=3559
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15089004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7290 4adac7df-926f-26a2-2b94-8c16560cd09d
- Thread::Release() wrote a local variable on the calling thread but read it on
another thread, with no synchronization. Happily it has no non-test callers
so deleting it instead of trying to fix it (see bug for details).
- Thread::started_ similarly was racily being written to; replaced with a
running_ Event, and hid the accessor except for tests & legacy callers,
with a note about why it's a bad idea.
webrtc/base patched with:
git diff origin --relative=talk/base | patch -p1 -dwebrtc/base
followed by manual merge of 3 thunks that ran afoul of naming differences
between talk/base and webrtc/base.
BUG=3388
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/14589005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6236 4adac7df-926f-26a2-2b94-8c16560cd09d
