search for: caramma

...quot;Jean-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 repr...

...uff/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...

...gested patch). 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 spe...

...al is scaled down to 14 bits before processing the coefficients of the predictor are calculated correctly and no artefact is introduced. Is anyone experiencing the same problem or has a proper fix for this? (I can work around the bug with input scaling for now). Thanks and best regards, Marcello Caramma -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20140611/c5769ed1/attachment.htm

...zes Undoes commits f7547a4e and 72513f3c This is what I used to configure: ../configure --prefix=$HOME/opus_install --enable-fixed-point These are the details of my system: uname -a Linux mcdebian 2.6.32-5-686 #1 SMP Mon Feb 25 01:04:36 UTC 2013 i686 GNU/Linux Best regards, Marcello Caramma

...As for using 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 shif...

...yp0[0] = 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...

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

...x 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, 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...

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

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

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

...rently your 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/...

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

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:

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

...lto:koenvos74 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 accumu...