similar to: opus Digest, Vol 70, Issue 1

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

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

We have found that it is possible to achieve a 30 to 50% reduction in MHz requirement for implementation of OPUS on Cortex M4 compared to the public version (v1.3 beta/v1.2.1). For the CELT configuration you mention (complexity 0, 16kHz, mono, 20ms) we are measuring a 4ms encode time and a 3ms decode time for that platform (32kbit/s). An important issue that I haven't seen much discussion

Hello All, We have been doing an optimised port of OPUS to a ARM Cortex A9. We are currently measuring between 20 and 90 MCPS for our code running on a Panda board (single core), this covers all bit-rates,sample rates for stereo coding (encode + decode) under normal operation. As Marc says complexity can be controlled via the API with our higher figure corresponding to the default setting of

Dear all In the paper section describes how CELT and SILK had implemented a look/up head delay of (2.5ms), (5ms) respectively , could you explain me> 1) those values are fixed. 1) how you guarantee those values independent of the architecture's performance. Thanks so much On Tue, Apr 18, 2017 at 10:05 AM, Diego Alejandro Parra Guzman < daparrag at correo.udistrital.edu.co>

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 >

On 11-04-11 06:48 PM, Shridhar, Vasant wrote: > Okay, > > Not exactly the answer I was looking for. This sounds like a big > change. I don't mind re-writing the LSP quantizer but re-training > code books and breaking compatibility is not what I want to do. I am > working on an optimization for an ARM cortex-A8. It is desirable to > process things in 4 element blocks.

Greetings all, We are proud to announce the release of LDTP 1.5.1. This release features number of important breakthroughs in LDTP as well as in the field of Test Automation. This release note covers a brief introduction on LDTP followed by the list of new features and major bug fixes which makes this new version of LDTP the best of the breed. Useful references have been included at the end of

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

Okay, Not exactly the answer I was looking for. This sounds like a big change. I don't mind re-writing the LSP quantizer but re-training code books and breaking compatibility is not what I want to do. I am working on an optimization for an ARM cortex-A8. It is desirable to process things in 4 element blocks. Is there a simpler approach you could recommend? Vasant Shridhar

Hello Jean-Marc, **Resending.. not sure why subject got removed earlier** Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr =

Hi, Can you apply this change to the MDCT test and run it again. See if more (all) sizes pass. Given the results, I strongly suspect an overflow. Jean-Marc On 08/05/15 01:21 PM, Viswanath Puttagunta wrote: > Hello Jean-Marc, > > Below are the results that show test_unit_dft passes, but > test_unit_mdct fails (only for nfft=480, 960, 1920) > Note: Tested on

> cortex-a8 vfpv4 with ffp-contract=fast : vfma instruction emitted ( this > seems a bug to me!! If cortex-a8 doesn't come with vfpv4 then vfma > instructions generated will be invalid ) If I'm understanding correctly, you've specifically told it this Cortex-A8 *does* come with vfpv4. Those kinds of odd combinations can be useful sometimes (if only for tests), so I'm not

Test case name : >> llvm/projects/test-suite/SingleSource/Benchmarks/Misc/matmul_f64_4x4.c - >> This is a 4x4 matrix multiplication, we can make small changes to make it a >> 3x3 matrix multiplication for making things simple to understand . >> > > This is one very specific case. How does that behave on all other cases? > Normally, every big improvement comes with

On Jul 2, 2009, at 6:24 PM, Neel Nagar wrote: > I suspect that my llvm-gcc cross compiler is using the wrong > assembler because it does not recognize "-mcpu=cortex-a8". This is a known problem. We've only added support for ARMv7 (including cortex-a8) in llvm in the last week or so, and the associated changes for llvm-gcc are still pending. Unless you need specific

Thanks for everyone giving their feedback! I saw pretty unanimous support for making -mcpu=generic the default and making -mcpu=generic schedule for an in-order CPU (Cortex-A8 in this case). I'll be making those changes shortly. I think the comments also make clear that it's less obvious whether we'd want -mcpu=native to become a default. It's probably good for some use cases, but

Questions about the port of Xen to ARM with virt extensions are best posted to xen-devel, the xen-arm list focuses on the PV port. Adding xen-devel since it seems you are mainly asking about the w/-virt-extensions port. On Fri, 2012-05-18 at 12:38 +0100, Krishna Pavan wrote: > Please inform the status of Xen-ARM for Cortex-A8 CPU''s on FME from > ARM. AFAIK no one has tried the

Hi Suyog, > I tested it on A15, i don't have access to A8 rightnow, but i intend to test > it for A8 as well. That's extremely dodgy, the two processors are very different. > I don't think i > will get A8 hardware soon, can someone please check it on A8 hardware as > well (Sorry for the trouble)? I've got a BeagleBone hanging around, and tested Clang against a

Greetings all, We are proud to announce the release of LDTP 1.7.0. This release features number of important breakthroughs in LDTP as well as in the field of Test Automation. This release note covers a brief introduction on LDTP followed by the list of new features and major bug fixes which makes this new version of LDTP the best of the breed. Useful references have been included at the end of