similar to: speex on TI C5x fixed-point DSP

Jean-Marc Valin wrote: >Hi Jamey, > >Really cool to see Speex being ported to the C55xx and I'd be glad to >integrate the changes required in Speex (and the style's fine with me). > > I have the encoder and decoder running now and have verified that the encoder is bit-exact wrt to the fixed-point code running on x86 for the same 30-second audio sample. Encode and

Hi Jamey, Really cool to see Speex being ported to the C55xx and I'd be glad to integrate the changes required in Speex (and the style's fine with me). Here are a couple comments on the patch you sent (I looked at it, but haven't compiled). 1) The changes you made to the pack un unpack functions would only work if the 16-bit chars are "big endian" (relative to the two bytes

I saw a thread in the list archives about a speex port to TI 55x DSP. Wondering how that worked out (is working out)? Also wondering if there is a source archive for it, or if the patch in the email archives is still current, or if there's been updates. Any info appreciated. Thanks Paul

Jamey, There is a previous posting in the speex archives with a link to the dsp c5x patch. Archive link: http://lists.xiph.org/pipermail/speex-dev/2004-October/002847.html Patch link: http://lists.xiph.org/pipermail/speex-dev/attachments/20041029/facb8c73/spee x-1.1.6-jeh1-0001.bin But that patch is very different (much smaller) then the dsp c5x patch at

Jean-Marc Valin wrote: >>I have the encoder and decoder running now and have verified that the >>encoder is bit-exact wrt to the fixed-point code running on x86 for the >>same 30-second audio sample. Encode and decode together run in >>real-time for 8KHz data, complexity=3, on 120MHz C5509 when code and >>data are all in on-chip SRAM. I have not tested the

Jean-Marc Valin wrote: >Hi Jamey, > >Really cool to see Speex being ported to the C55xx and I'd be glad to >integrate the changes required in Speex (and the style's fine with me). >Here are a couple comments on the patch you sent (I looked at it, but >haven't compiled). > > > Cool. >1) The changes you made to the pack un unpack functions would only

> I have the encoder and decoder running now and have verified that the > encoder is bit-exact wrt to the fixed-point code running on x86 for the > same 30-second audio sample. Encode and decode together run in > real-time for 8KHz data, complexity=3, on 120MHz C5509 when code and > data are all in on-chip SRAM. I have not tested the wideband codec yet. Cool! Just curious,

I have successfully DECODED speex on TI C5509: #define TESTENC_BYTES_PER_FRAME 20 /* 8kbps */ #define TESTENC_QUALITY 4 /* 8kbps */ I am trying to generate the files I need with speexenc.exe: speexenc -n --quality 4 -V male.wav male.spx But I can't decode the files on C5x. Yes, I have seen that speexenc.exe adds Ogg header and

> One thing I've noticed so far in the filter_mem2 code is the calls to > SATURATE(x, 805306368). 805306368 is 0x30000000. I was expecting that > to be on a bit boundary, say 0x3fffffff? In which case the arithmetic > saturation logic could be used. I don't think it would make that big of a difference, since the saturation is outside of the inner loop. If it's that

> For encoding into and decoding from "raw Speex stream" (if you can call > it that), I suggest you start with the sampleenc.c and sampledec.c > example code in Appendix B of the Speex Manual. There is no such a thing as a "raw Speex format". Also, sampleenc.c and sampledec.c are good for learning how to use the API, but the compressed format shouldn't be used in

Jean-Marc Valin wrote: >Well, I guess the first thing to look is whether your DSP can actually >do either 16x32=>48 or 16x32=>32 (keeping the MSBs), which is what the >smulwb does on ARM. If that's the case, you can gain a lot of speed (use >one instruction for 16x32 instead of three). Otherwise, replacing the >32x32 multiplies by 16x16 is probably a good thing. >

Jean-Marc Valin wrote: >>One thing I've noticed so far in the filter_mem2 code is the calls to >>SATURATE(x, 805306368). 805306368 is 0x30000000. I was expecting that >>to be on a bit boundary, say 0x3fffffff? In which case the arithmetic >>saturation logic could be used. >> >> > >I don't think it would make that big of a difference,

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

>> 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. For the persistent storage, the only change that I have made is to MAX_CHARS_PER_FRAME,

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?

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 Jean-Marc, I have tested Speex in fixed-point mode on my PC without clicking noise. As I mentioned below, I tested Speex in fixed-point mode running natively on the ARM side of the DaVinci without click noise. I only get the clicking noise when running Speex on the DSP side. For the TI C64+ DSP on the DaVinci processor, the TI-specific switches doesn't do much other than defining the

Hello, I'm porting CELT 0.7.1 to an embedded platform and unfortunately (at least for me) CHAR is defined as 16 bits. I now got the vocoder compiling but when i compare the encoded output with a windows build, they don't match. Among the other problems i think that the char definition is one of the biggest players. I've seen in arch.h the following definitions: /* 2 on TI C5x DSP */

I am wont to decode a speex 11kbps 8kHz 16bit to a raw data 8kHz 16bit LSB on a c5509. Trying to understand the "testenc-TI-C5x.c" exsample, but it looks to me wary complicated. Is there more documentation for the exsample or a decoder exsample available? Can somebody help? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL:

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.