similar to: SILK-implementation some questions

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>

Dear all, Sorry for this simple and maybe stupid question, I'm working in the implementation of opus for ARMv7e microcontroller using a library CMSIS/DSP used to calculate the CFFT and MDCT based on the DCT-IV. my question is: In the implementation of Celt you have used a fixed length CFFT equal to 1920, I want to know if there is some issues which can appear if a change that configuration

Dear all. According with my question. CELT CFFT size configuration I'm not completely sure about how the kiss_fft works for sizes which are not power of two, as occur in the case of celt which calculate the mdct using a fft sizes of 480, 240, 120, and 60, I guess that internally the input data is padded with zeros in order to compute efficiently the mdct using the Cooley and Tukey

Dear all I'm working on the implementation of the MDCT for the processor ARM-Cortex-M4 I'm trying to replicate the behavior of the MDCT for several overlapped values however I realized that current implementation of the MDCT is very close to the theory only in case in which we have and overlap exactly equal to N/2 where N is the size of the input vector as is shown in the examples for

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

Hi Dmitry, So it's not explicitly in your report, but it looks like the crash is due to a divide-by-zero at: min_coef = silk_DIV32_16( silk_int16_MAX, silk_RSHIFT( psSilk_VAD->counter, 4 ) + 1 ); which happens because counter is -16 (which means (-16 >> 4) + 1 == 0). Now, this could be caused by an integer wrap-around, but it should only happen after encoding around

Dear all, Currently I'm working in and optimization of opus for an arm-architecture *"armv7e-m"* I've involved in the general opus documentation as well in the architecture, however opus Is so big and difficult to discover specific optimization points, I want to know if you could give me a general view about of the principal points that I have to consider in order to optimize

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

opus\silk\enc_API.c silk_Encode() 168: if( ( ret = check_control_input( encControl ) != 0 ) ) { priority of the '!=' operator is higher than '=' operator fix: if( ( ret = check_control_input( encControl ) ) != 0 ) {

Hi Diego, Really, the only way to know what to optimize is to run a profiler. Optimizing without profiling is a waste of time and is often harmful. Cheers, Jean-Marc On 18/04/17 04:12 AM, Diego Alejandro Parra Guzman wrote: > Dear all, > > Currently I'm working in and optimization of opus for an > arm-architecture *"armv7e-m"* I've involved in the general >

Hi all: I'm successfully run OPUS in cortexM4 arm architectures using a cross compiler gcc-arm-none-eabi . I recommend to uses the following precompile flags before to compile you code: arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-dl16 -std=c99 -fasm -DARM_MATH_CM4 -DOPUS_ARM_INLINE_ASM -DOPUS_ARM_ASM .... and in your configuration file of OPUS you could use the

Hi, I've been trying to encode a live audio input from the microphone on iOS device using opus. Uncompressed audio recording works fine with http://theamazingaudioengine.com/ Then, when I tried to do encoding, I'm stuck at figuring out why the buffer is empty: static int ec_write_byte(ec_enc *_this,unsigned _value){ if(_this->offs+_this->end_offs>=_this->storage)return

Created corresponding unit test, and the optimization is bit exact with C function. --- silk/SigProc_FIX.h | 7 ++- silk/arm/arm_silk_map.c | 12 ++++ silk/arm/inner_prod_aligned_arm.h | 58 +++++++++++++++++++ silk/arm/inner_prod_aligned_neon_intr.c | 66 ++++++++++++++++++++++ silk/enc_API.c

* Published in IEEE Xplore * Google Scholar H5-Index = 22 ------------------------------ ---- Doctoral Symposium of CISTI'2023 ------------------------------ ------------ CISTI'2023 - 18th Iberian Conference on Information Systems and Technologies 20 - 23 of June 2023, University of Aveiro, Aveiro, Portugal http://cisti.eu/

Hi. I experienced same issue reported in https://gitlab.xiph.org/xiph/opus/issues/2026 The problem is that there are periodical(400ms) noise during DTX when the noise changed dramatically. I have found that the VAD value of silk does not affects to the DTX decision. If the background noise suddenly changes(by excessive echo cancellation, mute on/off operation, etc.) the silk generate a voice

Hi, I got libopus 1.2 from the download page. I compiled it using visual studio 2015 with your configuration (Release). I integrated opus.lib and the new include files in my own solution, but when I compile, I found 28 link errors (lnk 2001): - silk_Encode - ec_enc_init - celt_inner_prod_sse - opus_select_arch - silk_InitEncoder - ec_enc_shrink - silk_log2lin - ec_enc_bit_logp -

https://bugs.freedesktop.org/show_bug.cgi?id=98611 Bug ID: 98611 Summary: nouveau not working on gtx 970 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

hi folks. i've been experimenting with SILK codec and meet with some success on incorporating it in pjsip (an open source sip client). now i'm trying to do the same thing on Asterisk. any documentations, pointers, etc i should look into? any help is appreciated. -- Edwin Lam <edwin.lam at officegeneral.com> Systems Engineer, OfficeWyze, Inc. Ph: +1 415 439 4988 Fax: +1 415 283

Hi Marcello, Thanks for the report. It's hard to debug this without the actual file. Can you please post the sweep_in.raw file you used? Cheers, Jean-Marc On 11/06/14 04:46 AM, Marcello Caramma (mcaramma) wrote: > Hi, > > Apologies if this is a known issues, but I have found what I believe is > a bug in the fixed point implementation of the Silk codec and could not > find