search for: 32x16

...itialization and EXTEND32 *can* be defined as a function (e.g. for fixed-point debug). > Later I will check if this change makes these two builds match in the latest > SVN code. I fixed it in svn. Could you check that? > The MIPs are not a problem for me, and the C55 does very well on 32x16 > multiplies, so I have not played with PRECISION16 since last year. Does the C55 have a 32x16 multiplier or do you mean it handles my emulation of it well? Jean-Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signa...

...test > sample is lower than with the broken code (10.87 vs 11.10), but of course > this is no way to judge the real quality. SNR, especially on a single sample, can be very misleading. Yet, could you just check that the DSP results match what you get on a PC? > >Does the C55 have a 32x16 multiplier or do you mean it handles my > >emulation of it well? > > I has two ALUs with 17x17 bit MACs, and it has an instruction that does > this: > ACy = M40(rnd((ACx >> #16) + (uns(Xmem) * uns(Ymem)))) > > I never quite understood this, so I went of and looked a...

...it in svn. Could you check that? Now all platforms match again. Note that the measured SNR for this test sample is lower than with the broken code (10.87 vs 11.10), but of course this is no way to judge the real quality. >> The MIPs are not a problem for me, and the C55 does very well on 32x16 >> multiplies, so I have not played with PRECISION16 since last year. > >Does the C55 have a 32x16 multiplier or do you mean it handles my >emulation of it well? I has two ALUs with 17x17 bit MACs, and it has an instruction that does this: ACy = M40(rnd((ACx >> #16) + (uns(Xm...

...a PC. I have been using the 6-second test file male.wav from the Speex site for my simulations, if someone else wants to run the audio through the encoder and decoder at 8kbps, complexity 1. I might be able to get a coworker to do this, but not any time soon. >> >Does the C55 have a 32x16 multiplier or do you mean it handles my >> >emulation of it well? >> >> I has two ALUs with 17x17 bit MACs, and it has an instruction that does >> this: >> ACy = M40(rnd((ACx >> #16) + (uns(Xmem) * uns(Ymem)))) >> >> I never quite understood this,...

...above. I made ONLY this change to the 1.1.8 base that I am working from, and the problem is gone. I will go back to using fixed_generic.h for now, but it may still be worthwhile to make a custom version that takes advantage of the compiler intrinsics, which include 32-bit shifts, 16x16=32 and 32x16=32 MPY, and 32+16x16=32 MAC (with and without rounding). The multiply arithmetic all returns saturated results. It seems to me that can't hurt. Do you see any problem with using saturated MPY and MACs? By the way, the lsp.c change also fixes the TI C54x build, as expected. - Jim Crichto...

...ause the original Silk code is for 20ms. To convert the energy for 20ms, > it could have been doubled). When this is done the probability which is > updated in step2 becomes more than 1. When this is used in multiplication > in Step3, the value is treated as a negative number because its a 32x16 > multiplication. This is will result in a negative smooth coefficient. > Please let me know if this is a bug. > > > Thank you, > Chandrakala -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/201711...

...may be done because the original Silk code is for 20ms. To convert the energy for 20ms, it could have been doubled). When this is done the probability which is updated in step2 becomes more than 1. When this is used in multiplication in Step3, the value is treated as a negative number because its a 32x16 multiplication. This is will result in a negative smooth coefficient. Please let me know if this is a bug. Thank you, Chandrakala _______________________________________________ opus mailing list opus at xiph.org http://lists.xiph.org/mailman/listinfo/opus </blockquote> ------...

...Good. So I guess you are still having your low MIPS count, right? How much is that? > I will go back to using fixed_generic.h for now, but it may still be > worthwhile to make a custom version that takes advantage of the compiler > intrinsics, which include 32-bit shifts, 16x16=32 and 32x16=32 MPY, and > 32+16x16=32 MAC (with and without rounding). The multiply arithmetic all > returns saturated results. It seems to me that can't hurt. Do you see any > problem with using saturated MPY and MACs? Saturation never hurts. That's actually what I would have used if a...

...may be done because the original Silk code is for 20ms. To convert the energy for 20ms, it could have been doubled). When this is done the probability which is updated in step2 becomes more than 1. When this is used in multiplication in Step3, the value is treated as a negative number because its a 32x16 multiplication. This is will result in a negative smooth coefficient. Please let me know if this is a bug. Thank you, Chandrakala -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20171120/8fcd19c3/attachment.h...

...lexity 1, 8kbps, no preprocessor or jitter buffer or echo canceller (yet). >> I will go back to using fixed_generic.h for now, but it may still be >> worthwhile to make a custom version that takes advantage of the compiler >> intrinsics, which include 32-bit shifts, 16x16=32 and 32x16=32 MPY, and >> 32+16x16=32 MAC (with and without rounding). The multiply arithmetic all >> returns saturated results. It seems to me that can't hurt. Do you see >> any >> problem with using saturated MPY and MACs? > > Saturation never hurts. That's actually...

Hi Jim, > Build 11169 in SVN works correctly. Good. I'll try not to forget the EXTEND32 from now on. > I have attached a zip file (renamed > .txt) with a patch to bits.c to make the byteswapping for TI DSPs > consistent. Seems like unzip can't read it. Either it's in an unknown format or the file got corrupted. Could simply send as multiple (uncompressed)

...he energy for 20ms, it > could have been doubled). When this is done the probability > which is updated in step2 becomes more than 1. When this is > used in multiplication in Step3, the value is treated as a > negative number because its a 32x16 multiplication. This is > will result in a negative smooth coefficient. Please let me > know if this is a bug. > > > Thank you, > Chandrakala > > > _______________________________________________ > opu...

...ginal Silk code is for 20ms. To convert the energy for 20ms, >> it could have been doubled). When this is done the probability which is >> updated in step2 becomes more than 1. When this is used in multiplication >> in Step3, the value is treated as a negative number because its a 32x16 >> multiplication. This is will result in a negative smooth coefficient. >> Please let me know if this is a bug. >> >> >> Thank you, >> Chandrakala > > > _______________________________________________ > opus mailing list > opus at xiph.org > ht...

...16-bit accuracy (just define PRECISION16) and I suspect the difference > wouldn't be very large. Note that the quality isn't be as good with that > option on, whereas the changes I made recently don't hurt quality. The MIPs are not a problem for me, and the C55 does very well on 32x16 multiplies, so I have not played with PRECISION16 since last year. - Jim

...ode is for 20ms. To convert the energy for 20ms, >>> it could have been doubled). When this is done the probability which is >>> updated in step2 becomes more than 1. When this is used in multiplication >>> in Step3, the value is treated as a negative number because its a 32x16 >>> multiplication. This is will result in a negative smooth coefficient. >>> Please let me know if this is a bug. >>> >>> >>> Thank you, >>> Chandrakala >> >> >> _______________________________________________ >> opus ma...

Jean-Marc, >> I incorporated Stuarts fixed_c55x.h file, and that eliminated the >> artifacts, >> at the expense of a ~30% increase in MIPs. Now the male.wav file through >> encoder/decoder produces a bit-exact match with the C64x test that I did >> earlier. I will do some more testing to isolate the, but it may be a few >> days before I get to this task. As