In order to support different blocksizes for source and sink (e.g, for
4-to-1 beamforming/echo canceling which involves 4 record channels and 1
playback channel) the AEC API is altered:
The blocksize for source and sink may differ (due to different sample
specs) but the number of frames that are processed in one invokation of
the AEC implementation's run() function is the same for the playback and
the record stream. Consequently, the AEC implementation's init()
function initalizes 'nframes' instead of 'blocksize' and the source's
and sink's blocksizes are derived from 'nframes'. The old API also
caused code duplication in each AEC implementation's init function for
the compution of the blocksize, which is eliminated by the new API.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
I initially included put the Speex preprocessing assuming that we'd want
to use the digital gain control and noise suppression from Speex for all
echo cancelling implementations. In practice, we're probably going to
get entire implementations all processing in one package (WebRTC, custom
modules from various vendors, etc.).
This moves out this preprocessing and related knobs into the speex
implementation, which serves to clean out all implementation-specific
details from the module-echo-cancel core.
If module initialisation fails, the speex done() function might try to
free a value that's not been allocated yet. Adding protection for this
condition.
The adrian module was using home-brewed endianness conversion instead of
the appropriate mactos, and speex assumed a little-endian host. This
fixes both of these.
Optimises the core inner-product function, which takes the most CPU. The
SSE-optimised bits of the adrian echo canceller only if the CPU that PA
is running on actually supports SSE.
Since all algorithms will need to specify a block size (the amount of
data to be processed together), we make this a common parameter and have
the implementation set it at initialisation time.
Since the source and sink specification will need to be determined by
the AEC algorithm (can it handle multi-channel audio, does it work with
a fixed sample rate, etc.), we negotiate these using inout parameters at
initialisation time.
There is opportunity to make the sink-handling more elegant. Since the
sink data isn't used for playback (just processing), we could pass
through the data as-is and resample to the required spec before using in
the cancellation algorithm. This isn't too important immediately, but
would be nice to have.
