similar to: Opus encoder decoder MIPs Info Needed

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

Using -i should prevent failing if the files don't exist. --- appveyor.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appveyor.yml b/appveyor.yml index c85b0b1..ad9c6c0 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -17,7 +17,7 @@ build: verbosity: minimal after_build: -- cmd: 7z a opus.zip win32\VS2015\%PLATFORM%\%CONFIGURATION%\opus.lib include\*.h +- cmd: 7z

> I don't believe this is an actual error. If it's truly possible for > these areas to overlap (I don't think it is), then something much more > serious than using memmove instead of memcpy needs to be done about it. In the C# version of this code, these two copy regions are stored in separate arrays entirely. I agree that there should be no normal way to have the memcpy

Stack: (gdb) bt #0 0x0000000000aaf38a in silk_VAD_GetNoiseLevels (pX=pX at entry=0x7f26740297a0, psSilk_VAD=psSilk_VAD at entry=0x15897c38) at silk/VAD.c:315 #1 0x0000000000aa4a9d in silk_VAD_GetSA_Q8_sse4_1 (psEncC=0x15897c18, pIn=<optimized out>) at silk/x86/VAD_sse.c:177 #2 0x0000000000a9f92b in silk_encode_do_VAD_FLP (psEnc=psEnc at entry=0x15897c18) at

Hello all, after FOMS I decided to take a look at the opus library and I found that I could improve a bit the build system and cleanup the code a little bit. Most of the changes to the code has been suggested by my two tools cowstats and missingstatic (part of the ruby-elf gem if you care). HTH, Diego

hi, I am porting opus encoder to a low end device with 32K ram, 256K flash and 32MHz arm M3 mcu. But opus seems consume too much. To make it work , what I can think of 1, Only fixed point supported 2, Only mono voice application supported 3, Set complexity to zero 4, Support only one sample rate, like 16KHz 5, Silk mode only or Celt mode only My question is , before

Thank Jonathan! I'll fix the MAY_HAVE_NEON() in silk/arm/arm_silk_map.c Linfeng On Thu, Jun 1, 2017 at 3:34 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > Semantically, OPUS_ARM_MAY_HAVE_NEON is supposed to mean the compiler > supports, and the CPU may support, Neon assembly code, which isn’t > necessarily the same thing as the compiler supporting Neon intrinsics. >

Hi Jean-Marc, gdb out is "Program terminated with signal 8, Arithmetic exception." most likely this division by zero. you're right, this crash is reproduce on seq number 4294967265 (20ms rtp packet). This is about 994 days. "Jean-Marc Valin" <jmvalin at jmvalin.ca> писал(а):Hi Dmitry, > >So it's not explicitly in your report, but it looks like the crash

> > I am talking about the original sweep. > > The original sweep stops pretty close to 24 kHz. I mean the original sweep _as_encoded_, sorry.

Thanks Jean-Marc, I was able to get both encode and decode working the CC3220 device! But for bi-directional communication, I need decode and encode to occur in less time than the frame size I’m sending (20 ms). Currently decode takes 16~22 ms and encode is ~13 ms. What is the best way to try to reduce this time? Also, unsure why encode is taking less time than decode... I've also

Hello Thomas and Amit, Thanks for your notice and the detailed decode performance report. I describe the details of my encode/decode test on STM32F407ZG. A. opus version: latest 1.2.1 (TI: opus 1.1.2) B. KEIL 5.23 (TI: ARM compiler tool chain 5.2.7) C. setup the encoder as the below (fs is the sampling frequency) enc = opus_encoder_create(fs, chans, OPUS_APPLICATION_AUDIO, &opus_err);

Hi, I am working on trying to compile opus to be as small as possible. I have passed the FIXED_POINT and the DISABLE_FLOAT_API but I am looking into making this lib even smaller in size. Where can I find out about how to best strip this lib to only compile in what I need?

> As the thing is to encode for human ears (AFAIK), I'd say that 4kHz is already "quite high", > and I wonder who can actually hear pure 20kHz sine. If you read the beginning of RFC 6716, you learn that Opus never encodes any frequencies that are higher than 20 kHz. So at some medium or high bitrates, anything above 20 kHz is filtered out, not because of the bitrate but

Hello everyone, I tried integrating opus middleware on an STM32L4 microcontroller based project. First thing I noticed is the considerable amount of memory allocated by the opus_encoder_create function (nearly 40 kbytes if I recall). After modifying my project's memory setting (mainly heap size adjustments), I could bypass some aspects of this problems. What I'm noticing now is the time

The opus code default compiles on -o2 optimization level. I would like to change it to -o3. I have tried doing the changes in makefile.unix . The change is not getting reflected. I am building the code in Code composer studio for TI processor C6000. Could anybody help me with this -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thank Jean-Mark and Jonathan! I tested current OPUS encoder in floating-point with Complexity 8. Hacking using the attached patch (which will generate "#define OPUS_ARM_MAY_HAVE_NEON 1" in config.h) will speed up about 14.7% on my Chromebook. Probably it's because many NEON intrinsics optimizations can benefit both fixed-point and floating-point encoder. So if it's safe enough

I know the focus for Opus is low delay, but I've been watching its development with interest because of the potential for audiobook/podcast use, where latency is practically irrelevant. I hear the upcoming USAC codec will give good results for this niche (though listening test results don't seem to be available to the public yet), but I also hear it'll be extremely patent

Hello: We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files as well as variable level noise-only test files. This issue can be reproduced with opus v1.1 using this command: ./opus_demo voip 16000 1 25000 -dtx input.bin

Hi everyone, I've made several posts recently about CELT being "replaced" by the Opus codec ( http://opus-codec.org/ ) and I thought it was time to give an update on what's going on. As many of you know, I've been involved at the IETF on this new Opus codec, which essentially merge (a modified version of) Skype's SILK codec with CELT. This is more than just two codecs

Thank you Mark. I agree and have now updated the pull request with a new commit, addressing your comments. Please take a look. /Gustaf On Fri, 5 Apr 2019 at 11:41, Mark Harris <mark.hsj at gmail.com> wrote: > On 2019-04-01 3:37, Gustaf Ullberg wrote: > > Hi everyone, > > > > Some time ago, I sent a pull request > > <https://github.com/xiph/opus/pull/107>