search for: c54

Dear Sir\Madam; Thanks for your source codes. You mentioned that your speex source code can be compiled for ti-c54 family; but you use linux command-line as following to compile speex for C54 family: % ./configure -prefix=<path> -enable-ti-c55x % make % make install Is it true?! Then what is the output file for loading on DSP chip (C54)?? As I remember the compiled file for C5x family was *.out file....

> 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 all, thanks Jean for the codec. I am new to speech coding. Am interested to implement speex on a TI dsp, say C54. just downloaded speex v 1.1.6. when I removed optimisation flags for win32 in libspeex.dsp, I get a slightly different output for decoding using speexdec.exe (debug version). no prob for speexenc.exe except for some differences in the ogg header. for anyone interested, i have zipped some wav...

...clude 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 Crichton

Le mercredi 05 janvier 2005 ? 13:37 +0800, tunkeat a ?crit : > thanks Jean for the codec. My first name's Jean-Marc BTW :-) > I am new to speech coding. Am interested to implement > speex on a TI dsp, say C54. I think I've heard someone was working on that before... > just downloaded speex v 1.1.6. > when I removed optimisation flags for win32 in libspeex.dsp, > I get a slightly different output for decoding using speexdec.exe > (debug version). no prob for speexenc.exe except for...

...never hurts. That's actually what I would have used if all platforms supported it (which is at least not the case when ARMv4). If you send me a file with only the macros you want to override from fixed_generic.h, I can include it in the tree. > By the way, the lsp.c change also fixes the TI C54x build, as expected. What do you mean? Before that, it worked on C55, but not C54? Jean-Marc -- Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> Universit? de Sherbrooke

...value. 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. I will test the C54 build and send a patch tomorrow with updates to the .pjt files (adding window.c) and bits.c, as I described earlier. - Jim

Hi, I am using speex 1.2beta2 on a C5416, 16 bit, narrowband. The project I am implementing speex into is very limited in Data space. In the speex decode_init and encode_init there are allocs that, combined, take up 0x0F94 of data memory. I do not know why the various allocs are sized the way they are but that number is too big to f...

...> you send me a file with only the macros you want to override from > fixed_generic.h, I can include it in the tree. Good, but I will not get around to this for a while. My next step is getting a multichannel version working on C64x. >> By the way, the lsp.c change also fixes the TI C54x build, as expected. > > What do you mean? Before that, it worked on C55, but not C54? No, they have always produced the same results. The C54x seems to take about 5x as many cycles to do the task. I can see that 32x32 multiplies are being done by library calls rather than inline, so I w...

...ppens, 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) in svn. Could you check if that's the case? > I will test the C54 build and send a patch tomorrow with updates to the .pjt > files (adding window.c) and bits.c, as I described earlier. Good, thanks. Jean-Marc

step 1 [Image: http://www.gimptr.com/gimptribay/step1.png ] step2 [Image: http://www.gimptr.com/gimptribay/step2.png ] What can i do?

...asier (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 to make the byte swapping uniform for the TI C55 and C54 builds. - Jim ----- Original Message ----- From: "Jean-Marc Valin" <Jean-Marc.Valin@USherbrooke.ca> To: "Jim Crichton" <jim.crichton@comcast.net> Cc: <speex-dev@xiph.org> Sent: Thursday, April 20, 2006 7:13 PM Subject: Re: [Speex-dev] Major internal changes...

...you can tweak the sizes in config.h. You just have to declare the variable and add this init before the call to speex_encoder_init, and go back and look at the variable after you run some data through. #ifdef STACKDBG spxGlobalScratchFree = spxGlobalScratchPtr; #endif If you think that the C5416 build is broken, then (as Jean-Marc said) tell us what version you are using. There is a C54x project in the speex source tree that runs directly in the Code Composer simulator. If that fails in the latest code, let me know and I will work on tracking it down. As Jean-Marc indicated, this buil...

...larger because some line ends got changed in a couple of the files > when the first patch was applied. I am sorry for the clutter, but its my > first time with the patch tool. > > I have one lingering concern. The C6x encoder does not produce the same > results as the C55x and C54x. The waveform reproduction is less accurate as > measured by a sample by sample comparison. In the test programs, the SNR is > 11.10 in the C55x and C54x, and 10.79 in the C6x build. I figured that the > encoders might not produce bit-exact results because of differences in their &...

...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) in svn. Could you check if that's the > case? > >> I will test the C54 build and send a patch tomorrow with updates to the >> .pjt >> files (adding window.c) and bits.c, as I described earlier. Build 11169 in SVN works correctly. I have attached a zip file (renamed .txt) with a patch to bits.c to make the byteswapping for TI DSPs consistent. I also a...

...n tweak the sizes in config.h. You just have to declare the variable and add this init before the call to speex_encoder_init, and go back and look at the variable after you run some data through. #ifdef STACKDBG spxGlobalScratchFree = spxGlobalScratchPtr; #endif If you think that the C5416 build is broken, then (as Jean-Marc said) tell us what version you are using. There is a C54x project in the speex source tree that runs directly in the Code Composer simulator. If that fails in the latest code, let me know and I will work on tracking it down. As Jean-Marc indicated, this buil...

...you can tweak the sizes in config.h. You just have to declare the variable and add this init before the call to speex_encoder_init, and go back and look at the variable after you run some data through. #ifdef STACKDBG spxGlobalScratchFree = spxGlobalScratchPtr; #endif If you think that the C5416 build is broken, then (as Jean-Marc said) tell us what version you are using. There is a C54x project in the speex source tree that runs directly in the Code Composer simulator. If that fails in the latest code, let me know and I will work on tracking it down. As Jean-Marc indicated, this buil...

Hi, I am using 1.2beta2 on a C5416 doing narrowband in the decode function I am having a problem with the execution of my program vectoring off to random interrupts that are not used. I have tracked down the error to the highpass function called in nb_decode -very close to the end of the function-context: it is called here:...

On 02/18/2015 03:01 PM, Renato Golin wrote: > So it seems that you're one of the very few people that doesn't use > ToT. Almost everyone else uses it and the progress of LLVM kind of > assume you do. My company also does not use ToT. Being able to associate a product with a well-known release is *very* important to us. It enables communication with our customers. It allows