Select "processing" rates based on the input and output sampling rates.
Resample the input streams to those rates, and if necessary to the
output rate.
- Remove deprecated stream format APIs.
- Remove deprecated device sample rate APIs.
- Add a ChannelBuffer class to help manage deinterleaved channels.
- Clean up the splitting filter state.
- Add a unit test which verifies the output against known-working
native format output.
BUG=2894
R=aluebs@webrtc.org, bjornv@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9919004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5959 4adac7df-926f-26a2-2b94-8c16560cd09d
Long, long ago, webrtc didn't support audio at 44.1 kHz. As a result we
treated 44.1 kHz audio as 44 kHz. We now have an arbitrary rate
resampler and have no trouble supporting 44.1 (see 1395 for all the
details). I must have missed updating iOS at the time.
This shouldn't result in a visible change as 16 kHz is selected as the
preferred hardware rate.
BUG=1395
R=fischman@webrtc.org, henrikg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10949004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5957 4adac7df-926f-26a2-2b94-8c16560cd09d
proxy already set to same transport channel impl.
Since session can call SetImplementation multiple times with or without BUNDLE, there are cases when SetImplementation is called with same impl (OnRemoteCandidates/PushdownTransportDescription/SetupMux). Also variables in
cricket::TransportProxy like |connecting_| and |negotiated_| are accessed
both between worker thread and signaling threads (which calls for bigger change
on how session interacts with Transport and TransportChannelProxy). I have a created a separate bug to address later issue.
Also if single thread used as worker and signaling thread, we can end up
calling SetLocalDescription and OnRemoteCandidates in same call sequence, which
will end up calling SetImplementation twice.
R=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12019007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5944 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
Since PeerConnection holds a ref to its creating PeerConnectionFactory, it's
possible for ~PeerConnectionFactory() to be run on its signaling thread.
Deleting a thread from within that thread is sad times, so don't do it.
It would be nicer to avoid having PeerConnection hold a ref to the factory,
and instead require the user to keep the factory alive. Unfortunately that
changes the contract on PeerConnection{,Factory} and it's unclear how to vet
existing callers for safety.
BUG=3100
R=juberti@webrtc.org, noahric@google.com
Review URL: https://webrtc-codereview.appspot.com/11289004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5933 4adac7df-926f-26a2-2b94-8c16560cd09d
When checking whether we need to release external decoder,
we have to do pointer comparison. We can't rely on payload
types, because payload types can be stale (e.g. before we
decode the first video frame after RegisterReceiveCodec).
This leaves a dangling pointer to external decoder, which
leads to crashes later, after we actually delete the
external decoder object.
This change has been verified in Chromecast code tree.
BUG=chromium:335539
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12049004
Patch from Sergey Volk <servolk@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5922 4adac7df-926f-26a2-2b94-8c16560cd09d
Having this override in the .gypi file avoids having to set it for the bots, which I think is best if we can avoid.
This CL also reverts r5869 so video_capture_tests are compiled for Android again.
BUG=2974,3152
TEST=Successfully ran:
git try -t compile
git try --bot=win_baremetal,mac_baremetal,linux_baremetal -t video_capture_tests
git try --bot=android_apk,android_apk_rel
Verified the change in webrtc/build/apk_tests.gyp makes the build compile successfully from a Chromium+WebRTC configured checkout for Android APK tests.
R=fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11939004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5919 4adac7df-926f-26a2-2b94-8c16560cd09d
The design of VoeNetEqStatsTest in voice_engine_unittests depended on
being able to inject a factory for the audio coding module into
voice engine. This functionality is now likely going away, which would
make this test fail to compile. Further, the functionality under test
is mostly ACM functionality, wherefore it makes better sense to test it
at ACM level.
BUG=2996
R=henrika@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12029004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5912 4adac7df-926f-26a2-2b94-8c16560cd09d
