similar to: Slightly OT: Has SILK codec gotten anywhere?

On Wed, Oct 29, 2014 at 7:10 PM, sean darcy <seandarcy2 at gmail.com> wrote: > On 10/29/2014 08:06 PM, Matthew Jordan wrote: > >> On Wed, Oct 29, 2014 at 5:16 PM, sean darcy <seandarcy2 at gmail.com> wrote: >> >>> Can we expect a SILK codec for 13 ? Or does the one for 12 work for 13? >>> >>> >> codec_silk for Asterisk 12 will most

Can we expect a SILK codec for 13 ? Or does the one for 12 work for 13? sean

I need to extract SILK only FIXED POINT code. I have a couple of questions in this regard. 1. Is it enough to enable compile time flag (FIXED_POINT) in the config.h, include silk_fixed library and exclude silk_float in the opus_demo project. I am working in the MSVC framework. Anyone has tried this before? 2. It seems there is no compile time flag to enable SILK only code, the core

Using 11.4.0, trying to use SILK on the cell phone to ulaw over gv, but no success: [Jun 10 16:18:22] WARNING[4090][C-0000000a]: channel.c:6164 ast_channel_make_compatible_helper: No path to translate from SIP/ng-00000000 to Motif/+12025551212 at voice.google.com-da3c [Jun 10 16:18:22] WARNING[4090][C-0000000a]: app_dial.c:3032 dial_exec_full: Had to drop call because I couldn't make

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 any mention on this in the archives. The bug can be easily reproduced with the fixed point demo program (./configure ?enable-fixed-point ?disable-float-api && make) using the following command: ./opus_demo voip 16000 1 23000

I'm building asterisk 11 beta 2. I've been using silk a lot. I don't see silk listed in menuselect as a codec. But I also don't see an asterisk 11 silk codec on http://downloads.digium.com/pub/telephony/codec_silk. Do we use the asterisk 10 codec_silk.so ? sean

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

Is there a configuration or compile flag that lets me disable the SILK portion of the codec and use CELT only? I could have sworn that there is something, but I can't seem to find it in the mailing list archives. The application here is that I am attempting to update from the old CELT codec to OPUS. Unfortunately, the CELT codec was running *very* close to the CPU (MIPS32--80MHz) limit

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 saw the custom API, but nothing explicitly says "CELT-only" just "custom sample rate and frame size". I'll dig further now that you've pointed me in a direction. Thanks, -a On 7/6/15, 6:18 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I believe what you want is called Opus custom (OPUS_CUSTOM in the > code).

Hi, I am new to working with silk codec. I am doing silk codec file conversion to mp3. I am unable to decode its failing. Can you please let us know how to use and fix. The issue. Regards, Venkatarao B. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170125/a9bcc4a6/attachment-0001.html>

Yes, regarding the unsigned to signed conversion you are right, it is implementation defined. I just had an issue a couple of years ago with a compiler which incorrectly treated unsigned overflow as undefined rather than implementation defined? Regarding the 64 bit profiling: I looked at the disassembly (gcc ?c ?S ?O2 ../opus/silk/sum_sqr_shift.c ?I../opus/include ?I../opus/celt) of the 64 bit

Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/shorter, which is

Hi Jean Marc, please find attached the audio file (mono 16khz). I shortened it to about 10 seconds. I also add 2 patches that worked for me. Further info that might help: - The problem seems to be related to silk_burg_modified not reaching the maximum gain, so the actual filter order is 16 rather than 2 (which is what would be expected with a sine wave). - The problem seems to happen when

Hi, Does anyone have the CERT SiLK tools packaged for CentOS 6.x? -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com

Hi, Attached is a patch with silk/tests/test_unit_optimization_LPC_inv_pred_gain which does the unit test of silk_LPC_inverse_pred_gain() optimizations. Please review. The testing loop number is set to 10,000, since all branches in this function get hit after 9,085 loops of random inputs. Thanks, Linfeng -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

Hi Marcello, Thanks for the info and the proposed fixes. I'm currently investigating what's going on here before deciding on the best way to fix the problem. Have you been able to figure out why it doesn't work for rshifts >= 3? Cheers, Jean-Marc On 13/06/14 12:28 PM, Marcello Caramma (mcaramma) wrote: > Hi Jean Marc, > > please find attached the audio file (mono

Hi Marcello, It turns out that the problem has a much simpler explanation. As far as I can tell, it's actually a bug in silk_sum_sqr_shift() and this trivial patch appears to fix the problem: http://jmvalin.ca/misc_stuff/sum_sqr_shift_fix.patch It would still require some testing to check that the fix doesn't have any bad side effect. Let me know how well the fix works for you. Again,