similar to: Alleged bug in Silk codec

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 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 least 4 reasons: - It is less and simpler code - The result is likely to be slightly more accurate in case big numbers come early in the

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,

Hi Marcello, Actually, we were careful to avoid the undefined behaviour here. In fact, we are specifically running a clang test detecting undefined behaviour. If you look at the silk_SMLABB_ovflw() macro, you will see it is based on silk_ADD32_ovflw(), which is defined as: #define silk_ADD32_ovflw(a, b) ((opus_int32)((opus_uint32)(a) + (opus_uint32)(b))) By casting to unsigned, all the cases

Right, there shouldn't be a problem with undefined behavior. That said, a 64 bit implementation will work very well - in fact that's how it was done originally. The reason for the current implementation is to minimize 64-bit operations in order to improve performance on limited-width architectures. This functions gets used extensively, and I think the current implementation is faster on

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

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

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

KOEN VOS wrote: > current implementation is faster on a 32 or 16 bit processor. If you > would find the opposite to be true (ie that a 64 bit implementation is > faster on, say, a 32 bit ARM CPU) then perhaps we should reconsider. Doesn't ARMv6 have a dual signed 16x16->32 multiply with a 64-bit accumulator (SMLALD)? Even v5E should have a single 16x16->32 with a 64-bit

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 =

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.c b/celt/mdct.c index 1634e8e..fa5098c 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -276,8 +276,8 @@ void clt_mdct_backward(const mdct_lookup *l,

After a few experiments, I found that both alternatives are very similar, and 2~5% slower compared to the following: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..e490c3b 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -277,7 +277,7 @@ void clt_mdct_backward(const mdct_lookup *l, kiss_fft_scalar *in, kiss_fft_scala it in-place. */ { kiss_fft_scalar * OPUS_RESTRICT yp0 =

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:

Hello Opus, I?d like to report a bug in the fixed point OPUS code: line 336 (or thereabouts), operand FIND_LPC_COND_FAC should be replaced with SILK_FIX_CONST(FIND_LPC_COND_FAC ,32), otherwise multiplication by zero typically occurs. please confirm. Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL:

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp index 58092f4..93f7c2a 100644 ---

def STOREbos { // InstructionEncoding Instruction RPPInst RPPInstMMEMrr &nbsp; field bits<32&gt; Inst = { 0, 0, 0, 1, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; &nbsp; field bits<32&gt; SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Hi Krzysztof, Today I try it on llvm9.0.0 version. &nbsp; def bos : RPPInstMMEMrr<OPC_STORE, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (outs), (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !strconcat(opcodestr, ""), "$rs1,

> Have you tried compiling it yourself? I just installed git for the first time and downloaded all of the latest source code packages directly from the site. I'm getting the following every time I try to (re)build any of the projects: 1>------ Build started: Project: opus, Configuration: Release Win32 ------ 1> fatal: Not a git repository: 'C:\My

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!