GitLab

This new lib contains the bare minimum to implement an iSAC encoder and
decoder.

The webrtc files have been copied from the revision as the existing
imported files (c8b569e0a7ad0b369e15f0197b3a558699ec8efa).

The bug preventing us to pass the library object to
pkgconfig.generate() has been fixed in meson 0.52.

By doing so the generated pc file has the right -L linker flag, making
it easier to test the lib from non standard location.
We also no longer have to pass libraries_private, it will handle it
automatically.

In Meson we trust.

Svante authored Aug 31, 2019 and Samuel Thibault committed Aug 31, 2019

GNU/Hurd and GNU/kFreeBSD have basically the same userland as GNU/Linux,
just not the same kernel.

The assembly files used don't use the right comments for arm64

Mirko Vogt authored Jan 06, 2017 and Arun Raghavan committed Jan 06, 2017

Make *really* take '--with-ns-mode'-option into account.
Before it was bogus (wrong if-check) and it always resulted
in the float version being used.
Signed-off-by: Mirko Vogt <mirko-dev@nanl.de>

Thomas Petazzoni authored Aug 06, 2016 and Arun Raghavan committed Aug 10, 2016

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Thomas Petazzoni authored Aug 06, 2016 and Arun Raghavan committed Aug 10, 2016

The current architecture detection, based on the "host_cpu" part of the
tuple does not work properly for a number of reason:

 - The code assumes that if host_cpu starts with "arm" then ARM
   instructions are available, which is incorrect. Indeed, Cortex-M
   platforms can run Linux, they are ARM platforms (so host_cpu = arm),
   but they don't support ARM instructions: they support only the
   Thumb-2 instruction set.

 - The armv7 case is also not very useful, as it is not standard at all
   to pass armv7 as host_cpu even if the host system is actually ARMv7
   based.

 - For the same reason, the armv8 case is not very useful: ARMv8 is
   AArch64, and there is already a separate case to handle this
   architecture.

So, this commit moves away from a host_cpu based logic, and instead
tests using AC_CHECK_DECLS() the built-in definitions of the compiler:

 - If we have __ARM_ARCH_ISA_ARM defined, then it's an ARM processor
   that supports the ARM instruction set (this allows to exclude Thumb-2
   only processors).

 - If we have __ARM_ARCH_7A__, then we have an ARMv7-A processor, and
   we can enable the corresponding optimizations

 - Same for __aarch64__, __i386__ and __x86_64__.

In addition, we remove the AC_MSG_ERROR() that makes the build fail for
all architectures but the ones that are explicitly supported. Indeed,
webrtc-audio-processing builds just fine for other architectures (tested
on MIPS), it's just that none of the architecture-specific optimizations
will be used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Nicolas Dufresne authored Jul 04, 2016 and Arun Raghavan committed Jul 14, 2016

Those are used by generic RW lock implementation.

https://bugs.freedesktop.org/show_bug.cgi?id=96754

Nicolas Dufresne authored Jul 04, 2016 and Arun Raghavan committed Jul 14, 2016

https://bugs.freedesktop.org/show_bug.cgi?id=96754

Nicolas Dufresne authored Jul 04, 2016 and Arun Raghavan committed Jul 14, 2016

This is needed for windows build to be usable.

https://bugs.freedesktop.org/show_bug.cgi?id=96754

Nicolas Dufresne authored Jul 04, 2016 and Arun Raghavan committed Jul 14, 2016

This will also add it to the .pc file as WEBRTC_WIN leaks into the
public interface and undefined __STRICT_ANSI__ so M_PI is available.

https://bugs.freedesktop.org/show_bug.cgi?id=96754

Nicolas Dufresne authored Jun 30, 2016 and Arun Raghavan committed Jul 14, 2016

This otherwise breaks the build on Android and Windows. The flag is
required on some Linux builds, and is readded in a subsequent commit.

https://bugs.freedesktop.org/show_bug.cgi?id=96754

Nicolas Dufresne authored Jun 30, 2016 and Arun Raghavan committed Jul 14, 2016

https://bugs.freedesktop.org/show_bug.cgi?id=96754

Rex Dieter authored Jun 21, 2016 and Arun Raghavan committed Jun 21, 2016

Signed-off-by: Arun Raghavan <arun@arunraghavan.net>

Rex Dieter authored Jun 01, 2016 and Arun Raghavan committed Jun 01, 2016

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>

This corresponds to:

Chromium: 6555f9456074c0c0e5f7713564b978588ac04a5d
webrtc: c8b569e0a7ad0b369e15f0197b3a558699ec8efa

Expands on instructions for updating the code when upstream changes.
Also renaming with the '.md' extension for things that understand
Markdown.

This one is left over from a previous version of the code base.

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.