similar to: opus optimization on Arm-cortex M4F

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

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, Just to clear things up... So 1.1 has some new analysis code that increases the amount of CPU. When building as floating point (which you appear to be doing, right?), the new code is enabled at complexity 7 and up (opusenc defaults to complexity 10 IIRC). This is why you've been seeing an increase in the CPU time. In version 1.0.x, complexity 5-10 are the exactly the same for music.

Hi,I have a question about implementing opus codec and I appreciate you to answer it.I want to implement this codec on LPC1768 which has ARM cortex m3 and in keil uvision4, I don't know which file of opus library should be added to the project environment.Best regardsHamed KarbasiSharif University of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL:

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,

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 Fri, Oct 18, 2013 at 2:21 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Just to clear things up... So 1.1 has some new analysis code that > increases the amount of CPU. When building as floating point (which you > appear to be doing, right?), the new code is enabled at complexity 7 and > up (opusenc defaults to complexity 10 IIRC). This is why you've been >

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

On 2013-10-18 7:11 AM, Sebastian Reimers wrote: > Hello!, > > i've just compared the 1.0.3 release with the master branch > on a BeagleBone Black (AM335x 1GHz ARM Cortex-A8 with NEON > floating-point accelerator) and Arch Linux ARM. > > At the moment I dont no why, but I see that 1.1 is much slower > in encoding. Are there any default changes, that I missed and could

I'm considering implementing Opus as the codec for an embedded ARM-based battery powered audio system. In the interest of battery life and board footprint I'd like to specify the smallest CPU that can do the job. 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

Hello!, i've just compared the 1.0.3 release with the master branch on a BeagleBone Black (AM335x 1GHz ARM Cortex-A8 with NEON floating-point accelerator) and Arch Linux ARM. At the moment I dont no why, but I see that 1.1 is much slower in encoding. Are there any default changes, that I missed and could explain this? Normaly I suggested a better performance with 1.1 and the ARM

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 Dan, I suggest you try the code in git master, which has further ARM optimizations compared to 1.1. Cheers, Jean-Marc On 04/09/14 08:00 AM, Dan Nilsson wrote: > 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

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 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 =

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, I had the following errors when compiling the library for Cortex-m4 (-mcpu=cortex-m4) using the GNU compiler for ARM (gcc-arm-none-eabi-4_8). CPPAS celt/arm/celt_pitch_xcorr_arm-gnu.locelt/arm/celt_pitch_xcorr_arm-gnu.S: Assembler messages:celt/arm/celt_pitch_xcorr_arm-gnu.S:299: Error: thumb conditional instruction should be in IT block -- `ldrgt

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 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