similar to: Fwd: Patch, related to TI DSP C54x C55x C6x builds

Jean-Marc, I have attached a small patch with modifications to arch.h, bits.c, and misc.c. This contains the few mods remaining to support the various fixed point TI DSPs after the work that you did at the end of May (thank you for this). arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x and older C64x does not) bits.c: Allow external definition for max

Hi Jim, Thank for the patch. I'll apply it when I have a few minutes. If I haven't done so after a few weeks, please send it again. I'm in the process of relocating to Australia, so everything's a bit of a mess around here. Also, please post the c5X-specific files to the list (.cmd, .pjt, ...) so they'll be archived. Last thing, I see you defined spx_word64_t as long long for

The attached file contains build files for TI's Code Composer Studio (CCS) for the C54x, C55x, and C6x DSPs. I had intended to post this a couple of months ago, but it took a long time to get around to doing the little bit of cleanup required. This is a file I/O loopback application suitable for running with the CCS simulators, for evaluating memory and MIPs requirements for these

Jean-Marc, Here are the patches, broken out one per file. I did some additional work in the testenc files based on Peter Mlakar's post to make it easier (though still a bit klunky) to try different rates. These changes also incorporate the file window.c into the builds, change the decoder startup delay to account for the change in the algorithm delay from 10ms to 5ms, and change bits.c

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

Hi Jim, Thanks a lot for helping track problems with Speex. > There is a bit of work remaining to get the memory usage down for a > multichannel application. There have been some good posts over the > last couple of months about reducing memory usage. I think 1.1.8 incorporates all memory reductions proposed. Let me know otherwise. > Also, to nominally comply with the TI XDAIS

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

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)

Hello,   I have an OMAP5910 OSK board with C55 dsp and ARM9 processor. I just want to use speex as a simple application on the platform in order to check dsp's working well or not.   First, I found speex's source codes include "ti/speex_C55_test" directory so I thought speex could run on my platform well. Second, I open "Code Composer

>> Nice call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: maleout12may.wav Type: audio/wav Size: 95884 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20050524/57112d0c/maleout12may-0001.bin

> 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 Jean-Marc says, fixed_generic should

Stuart, Jean-Marc, >> 1) We need our own "fixed_xx.h" header file. I don't know why, and >> haven't >> had time to investigate, but there is a definite improvement when I use >> the >> attached fixed_c55x.h file which has turned all the maths into inline >> functions. > > Did you try with fixed_generic.h or just with fixed_debug.h?

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

> >I fixed 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. 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?

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

Jim, You're right, the memset really is there, how could I miss that? :) I also spoke too soon, as my change doesn't solve anything. At each run, something random causes the algorithm to either work or not work at all. There is a correspondence between whether the echo cancel works and whether the st->PHI and st->W arrays contain data or zeroes. (the arrays contain zeroes when alg

hi, am trying speex on TI c54x dsp. does anyone has any idea whether we can make both the coder AND decoder run in about 10ms for a 20ms frame for this dsp, looking at narrowband, no VAD/CNG/VBR, using a low complexity, say 1, for a midrange bitrate, say 15kbps? was the c55 dsp able to run real-time on speex for the above configuration? can someone share their timings? tia! oh yes, just

Jean-Marc, >> >I fixed 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. > > SNR, especially on a single sample, can be very misleading. Yet, could > you just check that the

Jean-Marc, >> 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