Things included in this CL:
- updated READMEs to provide an exact/reproable set of steps for getting the app
running.
- gyp changes to build the iOS AppRTCDemo sample app using gyp+ninja instead of
the hand-crafted Xcode project (which has never worked in its checked-in
form), including a gyp action to sign the sample app for deployment to an iOS
device (the app can also be used in the simulator)
- deleted the busted hand-crafted Xcode project for the sample app
- updated the sample app to match the PeerConnection API that ended up landing
(in a surprising twist of fate, the API landed quite a bit later than the
sample app and this is the first time the CR-time changes in the API are
reflected in the sample app)
- updated the sample app to reflect apprtc.appspot.com HTML/JS changes (equiv to
the AppRTCClient.java changes in http://s10/47299162)
- picked up the iossim DEPS to enable launching the sample app in the simulator
from the command-line.
- renamed some files to match capitalization of the classes they contain (Ice ->
ICE) per ObjC naming guidelines.
- ran the files involved in this CL through clang-format to deal with xcode
formatting craxy.
BUG=2106
RISK=P2
TESTED=unittest builds with ninja and passes on OS=mac; sample app builds with ninja and runs on simulator and device, though no audio flows from simulator/device (will fix in a follow-up CL)
R=andrew@webrtc.org, justincohen@google.com, wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1874005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4466 4adac7df-926f-26a2-2b94-8c16560cd09d
r4374 was mistakenly committed to stable, so this is to re-merge back to trunk.
Store the sequence number in StopSend() and resume it in StartSend().
When restarting the microphone device, we call StopSend() first, then
StartSend() later. Since we reset sequence number in StopSend(), it sometimes
causes libSRTP to complain about packets being replayed. Libjingle work around
it by caching the sequence number in WebRtcVoiceEngine.cc, and call
SetInitSequenceNumber() to resume the sequence number before StartSend().Store the sequence number in StopSend() and resume it in StartSend().
When restarting the microphone device, we call StopSend() first, then
StartSend() later. Since we reset sequence number in StopSend(), it sometimes
causes libSRTP to complain about packets being replayed. Libjingle work around
it by caching the sequence number in WebRtcVoiceEngine.cc, and call
SetInitSequenceNumber() to resume the sequence number before StartSend().
This patch fixes this problem by storing the sequence number in StopSend(), and
resume it in StartSend(). So that we can remove the workaround in libjingle.
BUG=2102
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1922004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4451 4adac7df-926f-26a2-2b94-8c16560cd09d
r4326 was mistakenly committed to stable, so this is to re-merge back to trunk.
Fixed the AGC and interface problems on the new path.
In order to make the AGC work properly, we need to cache the volume value passed
by the callback, compare it with the value returned by
shared->transmit_mixer()->CaptureLevel(). If they are the same, we need to
return 0 to indicate no volume needs changing, otherwise return the new volume.
By doing this, we avoid setting the volume all the same, which allows the users
to change the volume manually.
This patch also fixes some minor issues with the interfaces too: make the int
channel[] const, and correct the order of the input params in
channel::Demultiplex.
R=tommi@webrtc.org
BUG=[2134]
TEST=compile && manual AGC test
Review URL: https://webrtc-codereview.appspot.com/1921004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4450 4adac7df-926f-26a2-2b94-8c16560cd09d
r4326 was mistakenly committed to stable, so this is to re-merge back to trunk.
Add new interface to support multiple sources in webrtc.
CaptureData() will be called by chrome with a flag |need_audio_processing| to
indicate if the data needs to be processed by APM or not. Different from the old
interface that will send the data to all voe channels, the new interface will
specify a list of voe channels that the data is demultiplexing to.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1919004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4449 4adac7df-926f-26a2-2b94-8c16560cd09d
This is the conversation I had with Henrik Lundin regarding this problem.
Me:
In Expand::AnalyseSignal() we compute correlation and distortion, then calculate the ratio of correlation to distortion. There if distortion is zero we expect that correlation to be zero. Although in practice this might be true, I suppose we rarely hit into absolutely periodic signal, but in one of the tests the assertion in line 455 of expand.cc was triggered. The distortion is computed over a shorter length of the signal, while correlation is computed over longer segments. Therefore, I guess, if the signal has just enough zeros at the beginning we can end up in situation that distortion is zero but not the correlation. Do you agree? I didn't have time to attempt to solve this, but if my line of thought is correct, we should not have that assert. Perhaps, if correlation is zero we set the ratio to 0, otherwise, ratio would be the largest value of its own type. Any thoughts?
Henrik:
I agree with you. Go ahead with your solution.
R=minyue@google.com
Review URL: https://webrtc-codereview.appspot.com/1888006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4448 4adac7df-926f-26a2-2b94-8c16560cd09d
