search for: precision16

...essive, almost too good to be true. This is all straight > compiled C, after all (though the compiler has been updated also). I think this is probably due to some filters that got changed from 32-bit accuracy to 16-bit. There is an option to use *all* filters with 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. Jean-Marc

...d to be true. This is all straight >> compiled C, after all (though the compiler has been updated also). > > I think this is probably due to some filters that got changed from > 32-bit accuracy to 16-bit. There is an option to use *all* filters with > 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 w...

I'm trying to make a design decision between a TI 6416 or DM642 (fixed point) and 6713 (floating point) platform. The application is a 32 channel speech encoder. (CBR only, 8khz, 8kbps) To get a feel for the computational load, I am running 1 second (50 frames) of voice through the encoder. My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get below 720Mhz/32

...l. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought that a > 300Mhz floating point would come out even or ahead in an encoding > comparison. Instead of the 300M/32=9.3M cycles per channel that I need, I > see 71.5M cycles...

...nction (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-signature Size: 189 bytes Desc: Ceci est une partie de messag...

...l. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought that a > 300Mhz floating point would come out even or ahead in an encoding > comparison. Instead of the 300M/32=9.3M cycles per channel that I need, I > see 71.5M cycles...

...atch 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(Xmem) * uns(Ymem)))) I never quite understood this, so I wen...

...l. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought that a > 300Mhz floating point would come out even or ahead in an encoding > comparison. Instead of the 300M/32=9.3M cycles per channel that I need, I > see 71.5M cycles p...

...l. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought that a > 300Mhz floating point would come out even or ahead in an encoding > comparison. Instead of the 300M/32=9.3M cycles per channel that I need, I > see 71.5M cycles p...

Hi, I can see that there has been some effort to compile the SPEEX codec to operate on the TI c54x and c55x DSPs and I am wondering if anyone would be able to update the mailing list with their current MIPs and Memory resource requirements for their c54x and/or c55x compilation? The only estimate I was able to find in the mailing list archive was 42MIPs but I'm not sure if this is an

...d to be true. This is all straight >> compiled C, after all (though the compiler has been updated also). > > I think this is probably due to some filters that got changed from > 32-bit accuracy to 16-bit. There is an option to use *all* filters with > 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. > > Jean-Marc > -------------- next part -------------- A non-text attachment was scrubbed... Nam...

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already optimizations for ARM (*_arm4...

> You found it. The SHL32 (not SHR32) line fixes the problem. It must be > doing a 16-bit shift, then extending the result (which is reasonable). As > it happens, that it the same macro which gave us trouble last May > (25th/26th), when the C55 build was more subtlely broken. Yes, that's what I finally remembered. I think I've fixed all occurrences (by adding EXTEND32)