similar to: Master branch

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

Hi everyone, We finally made it! Opus is now standardized by the IETF as RFC 6716 (http://tools.ietf.org/html/rfc6716). See the announcements at: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/ http://www.xiph.org/press/2012/rfc-6716/ Feel free to spread those around :-) We're also releasing both 1.0.0 (same code as the RFC) and 1.0.1, which is a

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

Hi everyone, We finally made it! Opus is now standardized by the IETF as RFC 6716 (http://tools.ietf.org/html/rfc6716). See the announcements at: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/ http://www.xiph.org/press/2012/rfc-6716/ Feel free to spread those around :-) We're also releasing both 1.0.0 (same code as the RFC) and 1.0.1, which is a

I suggest you try it. I do know that it requires the dsp extensions, but it may work on a 24k. Just change the -march=74kc and see if it works. Jean-Marc On 22/06/14 11:26 AM, Dean Blackketter wrote: > Thanks for this. > > There?s not much documentation there. > > It appears that these optimizations are for MIPS 74K only and don?t apply to 24K-based builds, correct? > >

Hi Dean, It should work for 24kec, 34kc and 74kc cores. Thanks and Regards, Rhishi -----Original Message----- From: opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] On Behalf Of Dean Blackketter Sent: Monday, June 23, 2014 02:37 To: Jean-Marc Valin Cc: opus at xiph.org Subject: Re: [opus] MIPS optimizations Great, will do and report back. On Jun 22, 2014, at 9:13 AM, Jean-Marc

Nice! Looks good, thanks! On Thu, Dec 7, 2017 at 3:06 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > See proposed modification to your patch to avoid integer overflows and > work on 16-bit int platforms. > > Jean-Marc > > On 12/04/2017 07:08 PM, Drew Allen wrote: > > Hello, > > > > Attached is a patch that ensures only valid sizes of the

Hi Drew, On 11/13/2017 03:34 PM, Drew Allen wrote: > Does your encoder support ch253/254? Not at this point. Only families 0 and 1 are supported. I think adding family 2 shouldn't be relatively straightforward, but adding family 3 would require some thought. Cheers, Jean-Marc > Cheers, > Drew > On Mon, Nov 13, 2017 at 12:33 PM Jean-Marc Valin <jmvalin at jmvalin.ca >

Thanks for all the amazing work with ambisonics Drew et al. We're looking forward to the 1.3 final release and have already been successfully using the ambisonic work in production code. Varun -- Engineering Manager Facebook Audio ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 Jun 2018 13:02:18 +0100 From: Peter Robinson

Speex 1.2beta1 announcement: This new release brings many significant improvements. The quality has been improved, both at the encoder level and the decoder level. These include enhancer improvements (now on by default), input/output high-pass filters, as well as fixing minor regressions in previous 1.1.x releases. A strange and rare instability problem with pure sinusoids has also been fixed. On

Hey Jean-Marc, sorry about that... extra lines... was it whitespace? If so, sorry about that. Thanks! Cheers, Drew Cheers, Drew On Fri, Apr 28, 2017 at 2:43 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Oops, looks like we both should have been more careful. The patch had > some extra lines that shouldn't have been there. > > Jean-Marc > > On

Hello all! I've attached an updated patch for opusfile, based on formatting suggestions I got for the opus and libopusenc patches. Cheers! Drew On Thu, Mar 22, 2018 at 9:19 AM Drew Allen <bitllama at google.com> wrote: > Thanks! 2 down, 2 to go. :D :D :D > > On Wed, Mar 21, 2018 at 11:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca> > wrote: > >> Thanks, the

Hi Jean-Marc, Attached is an updated patch with your suggestions + additional corrections I caught over the weekend. Cheers, Drew On Fri, Nov 24, 2017 at 10:08 AM Drew Allen <bitllama at google.com> wrote: > Aha good point! Im travelling this weekend but will submit another patch > Monday morning. > > Cheers, > Drew > On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin

Hi Drew, I noticed you reverted the output[output_rows * i] = (tmp + 16384) >> 15; from the previous patch. That's still good. What should have been changed is the float version: output[output_rows * i] = (1/32768.f) * ((tmp + 16384) >> 15); which should just be: output[output_rows * i] = (1/(32768.f*32768.f)) * tmp; since there's no point in doing integer rounding when you

Hi, Just to let everyone know that I released libopusenc version 0.1.1. It does not change the API/ABI compared to 0.1, but fixes a few bad bugs. You can get it from https://www.opus-codec.org/downloads/ For those interested in testing it, there's an experimental patch to make opus-tools use libopusenc for the encoder:

Thanks, the libopus and the libopusenc patches are now merged. Cheers, Jean-Marc On 03/20/2018 12:36 PM, Drew Allen wrote: > Attached is an updated patch based on Jean-Marc and Mark's comments. :) > > Cheers, > Drew > > On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On

Done! On Tue, Nov 28, 2017 at 12:12 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > I only had a quick look, but your patch looks good except for the: > output[output_rows * i] = (1/(32768.f*128.f))*tmp; > > For floating point, you shouldn't do the >>7 either. Just remove the >>8 > from the floating-point calculation of tmp so that all the scaling is

Made a few minor tweaks to your patch (attached). Can you confirm you're OK with those and I haven't missed anything? Cheers, Jean-Marc On 12/04/2017 06:34 PM, Drew Allen wrote: > I've solely addressed this concern here. > > Cheers, > Drew > > On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>>

Hi Jean-Marc, (forgot cc opus@) Thanks for creating the unit test code. Attached is the updated optimization patch. On Mon, Feb 13, 2017 at 10:17 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 13/02/17 01:09 PM, Linfeng Zhang wrote: > > For 1), I agree that an explicit unit test would be a good plus to cover > > the cases that "make check" cannot

Hello Jean-Marc et all, I've attached an updated patch which I feel addresses all 3 cases. PTAL, Thanks! Cheers, Drew On Wed, Mar 7, 2018 at 8:39 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Make sure the modified libraries work in all of these three cases: > 1) libopus 1.2.1 > 2) libopus master (or 1.3-beta) with --enable-ambisonics > 3) libopus master (or