In investigating x86/sse2 issues in recent webrtc-audio-processing-0.2
release, I found that it was possible for libwebrtc_audio_processing to
contain undefined symbols.
Attached is a patch that addresses this:
* adds -Wl,--no-undefined to libwebrtc_audio_processing_la_LDFLAGS
* adds explicit -lpthread linkage (else, there are undefined references
to pthread-related symbols)
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
If we're breaking API, then clients need to be modified and recompiled
anyway, so we can avoid the cruft of trying to be backwards compatible.
Clients now need to include the file as it is in the upstream sources:
<webrtc/modules/audio_processing/include/audio_processing.h>
This is needed for at least the AudioFrame class.
Unfortunately, this does add a bit of ugliness because
module_common_types.h has video bits that are hidden behind our own
define, which now becomes part of pkg-config CFLAGS.
This could be made less ugly, potentially, but I'm not sure how right
now.
On x86, SSE optimisations are always compiled in, and used based on
runtime checks.
On ARM, we try to autodetect NEON support (with an option of runtime
detection). This has not been build-tested on ARM yet.
This leaves MIPS to be done.
Corresponds to upstream commit 524e9b043e7e86fd72353b987c9d5f6a1ebf83e1
Update notes:
* Pull in third party license file
* Replace .gypi files with BUILD.gn to keep track of what changes
upstream
* Bunch of new filse pulled in as dependencies
* Won't build yet due to changes needed on top of these
Corresponds to upstream commit 524e9b043e7e86fd72353b987c9d5f6a1ebf83e1
Update notes:
* Moved src/ to webrtc/ to easily diff against the third_party/webrtc
in the chromium tree
* ARM/NEON/MIPS support is not yet hooked up
* Tests have not been copied
