similar to: MIPS optimizations

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

Great, will do and report back. On Jun 22, 2014, at 9:13 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > 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. >> >>

Hi All, First time poster to this group, please ignore my ignorance? I?m trying to use Opus 1.1 on a 400MHz MIPS 24k CPU (AR9331, specifically, like in the Arduino Yun). I?ve successfully built (I think) opus-1.1 and opus-tools-1.8 and they run, but are dog slow. opus-1.1 does have the ?enable-fixed-point option set, as this chip only has soft-float. My short test file (less than one

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? On Jun 20, 2014, at 11:18 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > All those running Opus on MIPS should be interested in some new > MIPS-specific optimizations contributed by Imagination Technologies. For >

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

Hi Jean-Marc, Yes I confirm that we have done the same internal review on this patch. For 1), I agree that an explicit unit test would be a good plus to cover the cases that "make check" cannot trigger. If you like, we may submit an unit test patch for code review. Thanks, Linfeng On Thu, Feb 9, 2017 at 4:48 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng,

Hi, Attached is a patch with arm neon optimizations for silk_LPC_inverse_pred_gain(). Please review. Thanks, Linfeng -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170207/5c5ab508/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

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

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've solely addressed this concern here. Cheers, Drew On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > 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] =

I think you just attached the wrong (previous) version of the patch. Jean-Marc On 11/28/2017 12:24 PM, Drew Allen wrote: > Done! > > On Tue, Nov 28, 2017 at 12:12 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > I only had a quick look, but your patch looks good except for the: >   output[output_rows * i] =

Thank Jean-Marc! The speedup percentages are all relative to the entire encoder. Comparing to master, this optimization patch speeds up fixed-point SILK encoder on NEON as following: Complexity 5: 6.1% Complexity 6: 5.8% Complexity 8: 5.5% Complexity 10: 4.0% when testing on an Acer Chromebook, ARMv7 Processor rev 3 (v7l), CPU max MHz: 2116.5 Thanks, Linfeng On Wed, Apr 5, 2017 at 11:02 AM,

Hi Jean-Marc, Attached is an updated patch. I had to include some of Mark's suggestions in order to get the tests to work correctly. I will still submit a separate patch for him for a few other concerns he had after this one clears. Cheers, Drew On Thu, Nov 23, 2017 at 10:42 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Actually, there's also something wrong with the

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 done in float. Cheers, Jean-Marc On 11/27/2017 04:01 PM, Drew Allen wrote: > Hi Jean-Marc, > > Attached is

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 <jmvalin at jmvalin.ca> wrote: > 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

Hi Jean-Marc, Thanks so much for your review. Attached are my comments and an updated patch. On Mon, Oct 30, 2017 at 5:48 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I've had some time to dig more deeply into your patch. Here's some more > in-depth comments: > > 1) I note that your OpusMSEncoder struct in private.h adds a > subframe_mem[]

I attached a new patch with small cleanup (disassembly is identical as the last patch). We have done the same internal testing as usual. Also, attached 2 failed temporary versions which try to reduce code size (just for code review reference purpose). The new patch of silk_warped_autocorrelation_FIX_neon() has a code size of 3,228 bytes (with gcc). smaller_slower.c has a code size of 2,304

Sure, ill send that asap On Wed, Nov 8, 2017 at 4:44 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > Your ambisonics patch is already merged. Can you send a patch that > applies to master? > > Jean-Marc > > On 11/08/2017 07:05 PM, Drew Allen wrote: > > Hey Jean-Marc, > > > > I found a bug regarding exporting the matrix that

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 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. :) > > > >