similar to: Problems building on Raspberry Pi

Jean-Marc, I can try both of the things you suggested. Maybe this coming weekend. I installed the Raspbian libopus-dev package instead of building it myself and that's been working great. Do I use --disable-intrinsics on ./configure, or on make? On Thu, May 25, 2017 at 9:28 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Samuel, > > Can you see if this commit fixes

On 25/05/17 10:03 PM, Samuel Bearg wrote: > Do I use --disable-intrinsics on ./configure, or on make? --disable-intrinsics is a configure option. It will not compile any of the Neon code. By default, the library builds with Neon support, but only enables it when it detects that it can at run-time. The run-time detection didn't work with the unit tests and that's what my patch fixes.

Hi Samuel, Can you see if this commit fixes the problem: https://git.xiph.org/?p=opus.git;a=commitdiff;h=4507637cc Jean-Marc On 20/05/17 02:55 AM, Samuel Bearg wrote: > Hello, > > I'm following the directions that 'make check' gave me: to e-mail you > log files. > > I'm attempting to build opus on a raspberry pi zero w, which I think has > more or less

Hi, folks, I've been hunting down some strange bugs in audio I've been doing. While hunting my bugs down, I tripped across what appears to be an Opus bug, but it's not clear where it's coming from. Note that the optimization choices differ between the two in the config.log below. How can I force them to be the same? Presumably I need to force the android version toward the

Thank Jonathan! I'll fix the MAY_HAVE_NEON() in silk/arm/arm_silk_map.c Linfeng On Thu, Jun 1, 2017 at 3:34 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > Semantically, OPUS_ARM_MAY_HAVE_NEON is supposed to mean the compiler > supports, and the CPU may support, Neon assembly code, which isn’t > necessarily the same thing as the compiler supporting Neon intrinsics. >

Hi everyone, After much waiting, Opus 1.1.1 is finally here. The main changes are: - x86 SSE, SSE2 and SSE4.1 optimizations contributed by Cisco, - MIPS optimizations contributed by Imagination Technologies, - ARM Neon optimizations contributed by Linaro and ARM, - many architecture-independent optimizations, - memory footprint reductions, and - several minor bug fixes. The quality of the

Hello, I received feedback from engineers working on NE10 [1] that it would be better to use NE10 [1] for FFT optimizations for opus use cases. However, these FFT patches are currently in review and haven't been integrated into NE10 yet. While the FFT functions in NE10 are getting baked, I wanted to optimize the celt_pitch_xcorr (floating point only) and use it to introduce ARM NEON

Hi Linfeng, On 06/06/17 04:09 PM, Jonathan Lennox wrote: > Two comments on the various infrastructure for RTCD etc. > > 1. The 0002- patch changes the ABI of the celt_pitch_xcorr functions, > but doesn’t change the assembly in celt/arm/celt_pitch_xcorr_arm.s > correspondingly. I suspect the ‘arch’ parameter can just be ignored > by the assembly functions, but at least the

Hi, Optimizes celt_pitch_xcorr for ARM NEON floating point. Changes from RFCv3: - celt_neon_intr.c - removed warnings due to not having constant pointers - Put simpler loop to take care of corner cases. Unrolling using intrinsics was not really mapping well to what was done in celt_pitch_xcorr_arm.s - Makefile.am Removed explicit -O3 optimization - test_unit_mathops.c,

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work

Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv2: - Changes recommended by Timothy for celt_neon_intr.c everything except, left the unrolled loop still unrolled - configure.ac - use AC_LINK_IFELSE instead of AC_COMPILE_IFELSE - Moved compile flags into Makefile.am - OPUS_ARM_NEON_INR --> typo --> OPUS_ARM_NEON_INTR Viswanath Puttagunta (1): armv7:

Should call celt_inner_prod(). --- celt/bands.c | 7 ++++--- celt/bands.h | 2 +- celt/celt_encoder.c | 6 +++--- celt/pitch.c | 2 +- src/opus_multistream_encoder.c | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) diff --git a/celt/bands.c b/celt/bands.c index bbe8a4c..1ab24aa 100644 --- a/celt/bands.c +++ b/celt/bands.c

I wrote a proof of concept regarding the cpu capabilities runtime detection and choice of optimized function. I follow design which had been discussed on IRC. Also, i notice a little drawback: we must propagate the arch index through functions which don't have codec state as argument. However, if it's look good, i will continue to implement it. Best regards, -- Aur?lien Zanelli

From: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv1: - Rebased on top of commit aad281878: Fix celt_pitch_xcorr_c signature. which got rid of ugly code around CELT_PITCH_XCORR_IMPL passing of "arch" parameter. - Unified with --enable-intrinsics used by x86 - Modified algorithm to be more

Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv1: - Rebased on top of commit aad281878: Fix celt_pitch_xcorr_c signature. which got rid of ugly code around CELT_PITCH_XCORR_IMPL passing of "arch" parameter. - Unified with --enable-intrinsics used by x86 - Modified algorithm to be more in-line with algorithm in celt_pitch_xcorr_arm.s Viswanath Puttagunta

The following failures are consistent on buildbot (and my local box). The Clang one I think it's assuming an Intel box, the other two look like the FileCheck are not good enough. http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 Clang :: CodeGen/compound-assign-overflow.c LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll LLVM ::

On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote: > The following failures are consistent on buildbot (and my local box). [...] > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll It is interesting that I don't see this on my ARM box. Instead I see these: Failing