similar to: opus Digest, Vol 52, Issue 15

Hello, I am interested in porting OPUS to an embedded platform. The idea is that the encoder and decoder will run on different processors. In order to choose the proper platform, I need an estimate of the resources which are needed for OPUS. I read the following in the OPUS wiki: "The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.

Dear Christian van Bijleveld, You can use any of the below DSPs of Texas Instruments 1. TMS320C674x - This supports floating point implementation of opus 2. TMS320C66x - This supports both floating and fixed point implementations 3. TMS320C64x - This supports only fixed point implementation Regards, Mahantesh On Mon, May 13, 2013 at 10:12 PM, <opus-request at xiph.org> wrote: >

The e-mail sent to you contained an attachment with a not allowed filetype. Please inform the sender to pack this type of attachment into a password protected ZIP-archive. Eine an Sie gesendete E-Mail enthielt einen nicht erlaubten Dateianhang. Bitte informieren Sie den Absender, diese Art von Anhang kann nur als Passwort gesch?tztes ZIP-Archiv versendet werden. Details: Sender:

Hello, I am testing the command line based opus encoder/decoder tools and I have some questions regarding the information given by the encoder (see below as an example). Encoding using libopus 1.0.2 (audio) ----------------------------------------------------- Input: 48kHz 1 channel Output: 1 channel (1 uncoupled) 20ms packets, 64kbit/sec VBR Preskip: 312 Encoding complete

Hello, I just started into the world of OPUS. I would like to know what is the best way to build the Opus library and Opus tools on a Windows 7 pc. I see that the Opus library and the Opus tools packages have a few Makefiles. It also mentions mingw as an option for building. Is it somewhere explained what are the steps needed, or does anyone have some tips? Thanks, Met vriendelijke

Hi all, I am interested in using the OPUS codec for real-time application on an (preferable low-profile) platform. In order to choose the optimal processor (memory size, speed,...) I have the following questions: - We have compiled OPUS on a PC with Linux OS and on a dual-core Cortex A9 with Linux Kernel. Can OPUS run on a processor with no specific OS, or are there

Hi Drew, The float code should also be doing float multiplications. Make sure tmp is an opus_val32 and the multiplication itself casts to float rather than int32. Otherwise, the float version is likely to overflow. Jean-Marc On 11/30/2017 12:06 PM, Drew Allen wrote: > My apologies. I forgot to commit the changes before creating that last > patch. Yes, some in-house control would be good,

Following the thread from outside, I think Drew should work on in-house quality assurance ;-) > 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

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

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

On 11/09/2017 01:58 PM, Drew Allen wrote: > Attached is a quick patch that addresses a bug when exporting the matrix > from the encoder. Actually, I don't see what your encoder change is supposed to do. Are there cases where demixing_matrix->rows != nb_output_streams ? Cheers, Jean-Marc > Cheers, > Drew > > On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at

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 wasn't always grabbing > the correct values, causing incorrect mixing behavior. This patch > resolves that issue. > > Cheers, > Drew > > On

Hi all, Attached is a quick patch that addresses a bug when exporting the matrix from the encoder. Cheers, Drew On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at google.com> wrote: > 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

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

Still can't reproduce. What OS and compiler version? Jean-Marc On 21/04/15 02:48 AM, Suresh Thiriveedi wrote: > Hi, > > There is no change in the compiler flags. I'm using as it is from the > original code. No change in the Makefile and I believe it is using the > floating point only by default. > > We are using 8k samples and mono so the commands is as follows.

Hi Looks like 1.1 version is sensitive to the system architecture/compiler/kernel version. Below is my observation in various linux system I have. As you mentioned, you are not observed the crash in your system, can you please share your system details. And also please comment on the below table/observations. *Machine IP* *optimization flags* *RHEL version* *kernel version* *gcc version*

Hi Linfeng, I had a closer look at your patch and the code looks good -- and slightly simpler than I had anticipated, so that's good. I did some profiling on a Cortex A57 and I've been seeing slightly less improvement than you're reporting, more like 3.5% at complexity 8. It appears that the warped autocorrelation function itself is only faster by a factor of about 1.35. That's a

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

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