search for: mcaramma

Hi, Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. Note that libopus1.1, as extracted from the tar ball, is OK. Specifically, the tests that fail are in celt/tests/test_unit_mdct: nfft=32 inverse=0,snr = 85.341197 nfft=32 inverse=1,snr =

...tch). It might still be worth considering, as I personally found that easier to read (it also avoids calculating the central value twice for odd N4). Marcello ________________________________________ From: Jean-Marc Valin [jmvalin at jmvalin.ca] Sent: 22 February 2014 15:56 To: Marcello Caramma (mcaramma); opus at xiph.org Subject: Re: [opus] Make check failure on clone from 31 January Good catch! I think gcc is just unable to make use of restrict for anything useful. Apparently your compiler does, so could you benchmark both patches below and see if it makes a difference in terms of speed. If it&...

...S_MUL(re,t0) + S_MUL(im,t1); + yp0[1] = S_MUL(re,t1) - S_MUL(im,t0); + } } /* Mirror on both sides for TDAC */ Regards, Marcello On 05/02/2014 18:46, "Gregory Maxwell" <gmaxwell at gmail.com> wrote: >On Wed, Feb 5, 2014 at 8:05 AM, Marcello Caramma (mcaramma) ><mcaramma at cisco.com> wrote: >> Hi, >> >> Apologies if this is a known issue, but running make on revision >>e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when >>using fixed point configuration (floating point is ok) on my linux x86. >...

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

...qr_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, >thanks for investigating this. > >Cheers, > > Jean-Marc > >On 13/06/14 12:28 PM, Marcello Caramma (mcaramma) wrote: >> 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_...

...-Marc Valin" <jmvalin at jmvalin.ca> wrote: >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 any mention on this in the archives. >> >> The bug can be easily reproduced wit...

...ur compiler does, so could you benchmark both patches below and see if it makes a difference in terms of speed. If it's worth it, I can keep the restrict and add the odd case handling, but if not I'll just remove the restrict. Thanks, Jean-Marc On 21/02/14 05:54 PM, Marcello Caramma (mcaramma) wrote: > I tracked down the bug to an incorrect use of restrict. > > I would not consider this a compiler bug: we are lying to the optimizer by > telling it that a pointer is restrict when in fact it isn't. > > This can be fixed like so: > > > diff --git a/celt/mdct....

...sing the 64-bit version anyway, I'm not sure of the impact since I'm not the original author of the code. Koen, what are the advantages of silk_sum_sqr_shift() over the 64-bit version? See any issue with using one over the other? Cheers, Jean-Marc On 20/06/14 06:10 AM, Marcello Caramma (mcaramma) wrote: > Hi Jean-Marc, > > well spotted! The patch provided fixes the issue for me. > > Nevertheless, in my code (and I would suggest doing the same in libopus) I > am going to replace the function with one that accumulates on 64 bits and > then calculates the shift, for at...

On Wed, Feb 5, 2014 at 11:05 AM, Marcello Caramma (mcaramma) <mcaramma at cisco.com> wrote: > Hi, > > Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. > Note that libopus1.1, as extrac...

On Wed, Feb 5, 2014 at 8:05 AM, Marcello Caramma (mcaramma) <mcaramma at cisco.com> wrote: > Hi, > > Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. > Note that libopus1.1, as extrac...

...4 at gmail.com>> Date: Friday, 20 June 2014 22:04 To: "Timothy B. Terriberry" <tterribe at xiph.org<mailto:tterribe at xiph.org>> Cc: "opus at xiph.org<mailto:opus at xiph.org>" <opus at xiph.org<mailto:opus at xiph.org>>, Marcello Caramma <mcaramma at cisco.com<mailto:mcaramma at cisco.com>> Subject: Re: [opus] Alleged bug in Silk codec 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...

...ello, 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 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 > maxim...

...of the impact since > I'm not the original author of the code. Koen, what are the advantages > of silk_sum_sqr_shift() over the 64-bit version? See any issue with > using one over the other? > > Cheers, > > Jean-Marc > > On 20/06/14 06:10 AM, Marcello Caramma (mcaramma) wrote: > > Hi Jean-Marc, > > > > well spotted! The patch provided fixes the issue for me. > > > > Nevertheless, in my code (and I would suggest doing the same in libopus) > I > > am going to replace the function with one that accumulates on 64 bits and > &...

...blem: 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, thanks for investigating this. Cheers, Jean-Marc On 13/06/14 12:28 PM, Marcello Caramma (mcaramma) wrote: > 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 > maxim...

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

Has anyone succesfully compiled the 1.1 release for ti c6x (CC=cl6x)? I am currently struggling even to pass the first steps, due to the fact that for compilation and linking, the compiler requires -o <executable> at the end of the command, not at the beginning. So cl6x -o <executable> file.c will not work. This is what the configure script is trying when checking the environment:

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 any mention on this in the archives. > > The bug can be easily reproduced with the fixed point demo progr...