similar to: TI C6416 compiling issue

Bryan, Someone else just had this problem compiling for the C67xx. The problem was caused by the EXPORT keyword that is present in some files in 1.2rc1, but not in 1.2beta3 (had been added in svn build 14797, April, 2008). To fix it, just add the line: "#define EXPORT" in ti/config.h. Jean-Marc, a patch is attached. - Jim ----- Original Message ----- From: "Y

I started my project using the CodeComposerStudio speex_C64_test.pjt in speex 1.1.11.1. To build using floating point, I created a new project with the same files and modified ti\config.h to #undef FIXED_POINT. Is there a better way to configure a floating point processor? I have a few TI specific optimizations that could go into the next release. What's the procedure for submitting code?

The majority of a Speex encoder app does fit in a 6713. The 6713 has 8K of L1 and another 256K of memory 64K of which can be configured as L2 cache. (16,32,48, or 64K). One level of TI's website seems to incorrectly indicate only 64K of L2. I turned off MANUAL_ALLOC and have it allocating internal memory using calloc(). I did change the L2 cache to 2 way (32K) and adjusted the heap size to

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

Jerry, I think that just removing the FIXED_POINT define should be sufficient, though you mind want to turn off MANUAL_ALLOC, because I am not sure if the memory usage is identical for the fixed point build, and the constants in config.h are set for the fixed point build. Are you testing on the simulator, or on an eval board? It does not look like the 6713 has enough memory to hold Speex

At the Ogg Vorbis page for developers (http://xiph.org/vorbis/) one can find this line: "The Tremor reference decoder provides an integer-only implementation of the decoder for embedded devices [SVN trunk] [low-memory branch]" I'm interesting in using the integer-only implementation off ogg vorbis but I wonder: what is the difference between these two downloads? (SVN trunk and

Jean: The 6711 is actually a floating point processor so it can do the floating point without emulation. I am working on the 6416 which does not have it. Working with fixed point may still speed things up possibly. Muhammad: It seems like you might have to start getting into linear assembly to speed things up. If you are serious to getting speex working on TI DSP we should work together on

Hello! I'v downloaded speex lib 1.1.11.1. I am trying to port speex lib to Blackfin processor. I am using VisualDSP++ 4.0. If I am compiling source codes with using floating point everything ok. When I am compiling with FIXED_POINT defined everything's ok and code works about two times faster. But when I am defining BFIN_ASM I am getting several compiling errors in Blackfin assembler

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

New issues (0) ================================================= No new issue. Old issues (4): ================================================= 1) IA32E/PAE: 32bit Vista RTM network doesn''t work. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=840 2)time latency is a negative number on window guest when vcpu > 1 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=895 You

<speex-dev at xiph.org> Hi all, I'm a begginer with DSP and i need your help and suggestions. I'm trying to use the Speex and a DSP DM642 to implement a solution with voice! I'm using the 1.2 beta 3 distribution and the TI's Code Composer Studio v3.1 simulator. I coosed speex_C64_test.pjt and modified the speex_C64_test.cmd to only use the DM642 external RAM memory. I'm

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

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

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

> 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

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

Hi Randy, Thanks for reply. I have one question though. While compiling the speex (downloaded from http://downloads.xiph.org/releases/speex/speex-1.2rc1.tar.gz), I gave ./configure -enable-ti-c55x option and then built the library through make and make install using cygwin. In this case, I get this error "error: member "bits.o" of archive

> To get a feel for the computational load, I am running 1 second (50 frames) > of voice through the encoder. You might want to use a bit more just so you don't see the initialization complexity at all. > My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod()

Hi, I am a rails and ruby nuby :-) How do you pass data between different controllers and views? I have a page ( a quote) that I am editing url ....quote/edit/6 6 id the current id. I then go to a catalog (url....catalog) to add an item to my quote (I do this via a line_item file that the quote reads) I now want to go back to the quote. I have tried this <%= link_to ''Back to