similar to: Opus performance on Cortex-M4

Hi Andy, On 03/11/14 07:36 PM, Andy Isaacson wrote: > In some quick testing on Cortex-A8 (a very different core, but at least > ISA compatible and hopefully fairly similar to M4 for things like cycle > counts and code size) I saw promising results -- about 30 MHz of A8 CPU > was sufficient to encode an audio stream using the 1.1.1-beta fixed > point codec at 48 kHz mono,

What is the possibility to use the Cortex-M4 DSP instructions to fully optimize the OPUS code? Could we use the ARM CMSIS DSP library for this optimization? Thanks, Heng -----Original Message----- From: opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] On Behalf Of opus-request at xiph.org Sent: Tuesday, November 04, 2014 2:00 PM To: opus at xiph.orgis Subject: opus Digest, Vol 70,

Hi everyone, I have lately been evaluating the performance of various audio decoders, particularly for ARM devices (Cortex A8 / A9). The context is audio playback in a game engine, and thus decoding performance is of particular interest. Looking at Opus versus Vorbis on a Cortex A9 smartphone, the numbers look approximately like this: Vorbis (tremolo decoder) 9.3 Mb PCM/s Opus (libopus 1.1)

Hi, Thank you for your response. I pulled yesterday to commit da97db1ca1f92592af3534c9a2596da0e9a009ca, added a bunch of more defines to my compile options, and assembled & linked in armopts.s,celt_pitch_xcorr_arm.s. Performance jumped up from about 4.8 Mb/s to 5.3 Mb/s on the same device, so it is improvement. Not sure what other tweaks there would be to try, but if it could match the

Hi All, Cortex-M4 is a single issue CPU whereas A8 is dual issue so this is the main reason you are seeing a slow-down, use of NEON I would say is secondary, certainly for CELT. We (ESPICO) have done optimisation work on OPUS v1.1 and have ARM implementations about twice the speed of the 'off the shelf' version. Please contact me directly if you want to discuss further. Cliff

Hi, ./configure --build x86_64-unknown-linux-gnu --host arm-linux-gnueabihf --disable-assertions --disable-check-asm --enable-intrinsics CFLAGS=-O3 --disable-shared When configuring with floating-point and intrinsics enabled as above, the generated config.h only has OPUS_ARM_MAY_HAVE_NEON_INTR defined (to 1), with /* #undef OPUS_ARM_ASM */ /* #undef OPUS_ARM_INLINE_ASM */ /* #undef

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 all ! I just learned about the Opus codec and would like to try it out on my NRF52 (Cortex-M4) target.   I've been struggling a bit with the "trival_example.c" setup but repeatedly run into "hard fault" crashes when stepping through the code. Firstly; for a "bare bone" configuration, does the following compiler directives make sense ? UDEFS =

Thank Jean-Mark and Jonathan! I tested current OPUS encoder in floating-point with Complexity 8. Hacking using the attached patch (which will generate "#define OPUS_ARM_MAY_HAVE_NEON 1" in config.h) will speed up about 14.7% on my Chromebook. Probably it's because many NEON intrinsics optimizations can benefit both fixed-point and floating-point encoder. So if it's safe enough

Hi, I would like to use OPUS codec to compress and decompress an audio stream for full-duplex intercom application; I would like to use a microcontroller equipped with Cortex-M4 core without NEON running at 72MHz. Does the OPUS codec works fine on that architecture? Do you have some benchmark data? Thank you in advance. Best regards. Daniele -------------- next part -------------- An HTML

Hi, I'm planning to use Opus codec on a ARM cortex M7 device running at 400MHz. Con you please suggest the best configuration directives that I have to set in the config.h file in order to obtain the best perfromances on the cortex M7 architecture? Actually I have compiled libopus 1.2.1 with the following cnfiguration parameters: #define VAR_ARRAYS  1 #define FIXED_POINT  1 #define

Hi, I am trying to cross compile code for ARM Cortex m0, m3, and m4. For m0, I use: -target armv6--eabi -mcpu=cortex-m0 That seems to work. For m3 and m4, I use the following which does not work (fatal error: error in backend: CPU: 'cortex-m3' does not support ARM mode): -target armv7m--eabi -mcpu=cortex-m3 and -target armv7em--eabi -mcpu=cortex-m4 Who can help me with the

Hello All, I recently completed the porting of Opus Encoder on a Cortex M4 embedded controller. The decoder is yet to be done. Based on the chat discussion I would be putting CPU performance numbers for Encoder: Speech, 16KHz, 16-bit mono channel for the following combinations Complexity: 0,1,3,5,9 and Frame Size of 20 and 40ms for Output bit rate of 4Kbps and 8Kbps Any suggestions/critical

Hi everybody I wrote a couple of months ago about implementing the opus codec on a DK52 from Nordic (nrf52832 MCU, Cortex M4). In the meantime I got a bit further and would again like to ask some questions. My settings: I included all the opus files into my project (opus-1.2.1) Defined: FIXED POINT, VAR_ARRAYS, DISABLE FLOAT API, OPUS_BUILD, CELT_MODE_ONLY I am able to allocate enough memory

"Ehrenberg Nicolas" wrote: > Thanks for the reply. > For my application I unfortunately need a better signal reconstruction. It's > not necessarily a problem that the constant DC voltage is removed, but the > audio signal will need to be more exact because it's also studied visually. > To be more exact, I need to record and transmit audio data recorded from >

Thanks for the reply. For my application I unfortunately need a better signal reconstruction. It's not necessarily a problem that the constant DC voltage is removed, but the audio signal will need to be more exact because it's also studied visually. To be more exact, I need to record and transmit audio data recorded from animals (mostly birds). Are there ways to achieve a more similar

On 12 October 2013 23:00, Amara Emerson <amara.emerson at gmail.com> wrote: > Hi Jan, > > For Cortex-M0, you should probably use the armv6m string in the target > triple. For M3 and M4 you need to use the thumbv7m arch string, -mthumb > won't be necessary. > Yes, but I agree with Jim that a bug must be filled. Jan, would you mind filling a bug?

Hi Jan, For Cortex-M0, you should probably use the armv6m string in the target triple. For M3 and M4 you need to use the thumbv7m arch string, -mthumb won't be necessary. Amara On 11 October 2013 19:23, Jan Hoogerbrugge < jan.hoogerbrugge at biface-tools.com> wrote: > Hi, > > I am trying to cross compile code for ARM Cortex m0, m3, and m4. > > For m0, I use: > >

Hello everyone, For a private project I would like to make a new Internet Intercom device (for my kids and me). At the moment I use a separate DSP with Ogg/Vorbis (VS1053) but I like a challenge ;-) Is a eg. ST32F10x (cortex m3) or a new ST32F40x (cortex m4) powerful enough to do encoding and decoding ? Any existing projects to learn from? Thanks for your time, Edwin van den Oetelaar

I've got a trivial fix for this problem, and another one which manifests when thumb is given without an explicit CPU. I'll start pushing it through our submissions process. On Saturday, 12 October 2013, Renato Golin wrote: > On 12 October 2013 23:00, Amara Emerson <amara.emerson at gmail.com<javascript:_e({}, 'cvml', 'amara.emerson at gmail.com');> > >