similar to: Fix for lsp.c for 16-bit platforms (TI C55x DSP)

Hi Jean-Marc, Hi Jim, I have also seen some problems with the 1.1.8 release on the C55x. So far I have boiled down the issues to the following: 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.

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

Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a

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

> 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 changes include adding an EXTEND32 to the line above.

For me, this was a memory allocation problem. I am using a private heap, and somewhere between build 11522 and 11700, the allocation for two large buffers was changed from calloc to speex_alloc (I am sure that this was a cleanup change, and I have not had a chance to locate it yet). This was overrunning my heap, and enlarging the heap solved the problem. I suspect that Itay is having a

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

Hello, I am interested in using the CELT codec for an embedded project around the DSP C55x family from TI. Is this someone has already done? Which is necessary to do that, which compiler, is there a specific configuration ? Is it necessary to have an Operating system to run the CELT codec ? Is it possible to instantiate several times the CELT codec ? Thank you in

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

hey guys, I am using the tip of Git and attempting to compile for a C55x DSP. I am running into a couple compile errors and have found the source of the issue. The errors: "celt.c", line 957: error: declaration may not appear after executable statement in block as well as "celt.c", line 2303: error: declaration may not appear after executable statement in block Both of

Jim Crichton, I'm trying to run speex on omap 1610 platform and i saw that you have a patch for c55. When i saw your mail about this, i decided to ask you for send me those files above: include\config.h (not automatically generated, sets memory sizes, enables manual alloc) include\speex\speex_config_types.h (match Speex types to compiler types, not generated from types.in

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

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

I rebuilt the TI DSP build for the C55 this morning, in order to add the window.c file to the TI project. I encountered two problems: 1. I got a compile error at line 410 in nb_celp.c, because this compiler will not allow variable declarations in the midst of executable code. I fixed this by bracketing this code block: line 410: { /* Added */ spx_word16_t *exc16_alias =

> I was wrong, it is the encoder that is not working, and it stopped working > in build 11103. The log message for this build is "another 640 bytes > removed from the encoder state (using the input data instead of copying it > to st->frame/st->inBuf)". Only nb_celp.c/h are changed in this build. What > I am seeing out of the decoder is an extremely low signal

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

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

> The C5x and C6x output diverges in build 10143, which has log message "lpc > floor converted to fixed-point." Also, the measured SNR changed from 11.05 > in builds 9854-10141 to 9.22 and 9.24 in 10143. Actually, build 10143 introduced another bug, that was the reason for the 1.1.11.1 release. > There is just four lines in modes.c which declare the constant, and one

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)