This provides more flexibility if some component in AudioProcessing wants to operate before downmixing.
Now the AudioProcessing does only track the processing rate, but not the processing number of channels. This is tracked by the AudioBuffer itself and can be changed at any time to one smaller or equal the input number of channels. For each chunk it is reset to input number of channels and the end it should be equal to the output number of channels.
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/28169004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7879 4adac7df-926f-26a2-2b94-8c16560cd09d
Implemented the 3 bands splitting filter bank by:
1. Upsample by 4/3.
2. Split twice into 2 bands.
3. Discard upper most band, because it is empty anyway.
A unittest was also implemented:
1. Generate a signal from presence or absence of sine waves of different frequencies.
2. Split into 3 bands and check their presence or absence.
3. Recombine the bands.
4. Calculate delay (as it is an IIR it depends on frequency).
5. Check that the cross correlation of input and output is high enough at that delay.
BUG=webrtc:3146
R=andrew@webrtc.org, bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31029004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7754 4adac7df-926f-26a2-2b94-8c16560cd09d
This doesn't change the behavior at all.
The logic behind this is having one class which manages all the splitting filters, because in the future we plan to add a 3 band one for 48kHz support.
It also breaks the dependency of the AudioBuffer with the filter states of these filters (which are going to be different for the 3 band one). The AudioBuffer is complicated enough and is going to need changes to support 3 bands in the future, so any simplification is a good idea.
On top of that it eliminates repeated code in the APM (now only iterating over channels, but then also deciding in how many bands to split). This should be managed by the AudioBuffer directly.
BUG=webrtc:3146
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/32469004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7705 4adac7df-926f-26a2-2b94-8c16560cd09d
The data_ optimization was a way to operate on the data directly
instead of copying it, applicable in the mono, non-float case. Since a
few audio_processing steps are already using floats (with more
hopefully to come), we don't end up benefiting from the optimization
anyway, so we might as well remove it.
BUG=
R=aluebs@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15539004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6307 4adac7df-926f-26a2-2b94-8c16560cd09d
We want to remove energy_ entirely as we've seen that carrying around
this potentially invalid value is dangerous.
Results in the removal of AudioBuffer::is_muted(). This wasn't used in
practice any longer, after the level calculation moved directly to
channel.cc
Instead, now use ProcessMuted() in channel.cc, to shortcut the level
computation when the signal is muted.
BUG=3315
TESTED=Muting the channel in voe_cmd_test results in rms=127.
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/12529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6159 4adac7df-926f-26a2-2b94-8c16560cd09d
Each audio processing step is given a pointer to an AudioBuffer, where
it can read and write int data. This patch adds corresponding
AudioBuffer methods to read and write float data; the buffer will
automatically convert the stored data between int and float as
necessary.
This patch also modifies the echo cancellation step to make use of the
new methods (it was already using floats internally; now it doesn't
have to convert from and to ints anymore).
(The reference data to the ApmTest.Process test had to be modified
slightly; this is because the echo canceller no longer unnecessarily
converts float data to int and then immediately back to float for each
iteration in the loop in EchoCancellationImpl::ProcessCaptureAudio.)
BUG=
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18399005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6138 4adac7df-926f-26a2-2b94-8c16560cd09d
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
This is mainly to support the native audio format in Chrome. Although
this implementation just moves the float->int conversion under the hood,
we will transition AudioProcessing towards supporting this format
throughout.
- Add a test which verifies we get identical output with the float and
int interfaces.
- The float and int wrappers are tasked with conversion to the
AudioBuffer format. A new shared Process/Analyze method does most of
the work.
- Add a new field to the debug.proto to hold deinterleaved data.
- Add helpers to audio_utils.cc, and start using numeric_limits.
- Note that there was no performance difference between numeric_limits
and a literal value when measured on Linux using gcc or clang.
BUG=2894
R=aluebs@webrtc.org, bjornv@webrtc.org, henrikg@webrtc.org, tommi@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9179004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5641 4adac7df-926f-26a2-2b94-8c16560cd09d
