search for: c5x

...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 have deleted the first 396 byte's of the file for test. Where am I going wrong? Can I generate with speexenc.exe raw speex files for the C5x? Regards Peter -------------- next part -------------- An HTML attachment was scr...

...;> #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 have deleted >> the first 396 byte?s of the file for test. >> >> Where am I going wrong? >> >> Can I generate with speexenc.exe raw speex files for the C5x? >> >> Regards >> &gt...

...op in the code that goes past 2^15. Jean-Marc On jeu, 2004-09-16 at 16:53 -0400, Jamey Hicks wrote: > Greetings, > > I've just started porting speex to a TI C5509 DSP. It doesn't look like > it's going to be too painful, but there are a couple of quirks about the > C5x. > > 1) chars are 16 bits because memory addresses are for 16bit words > 2) ints and short are also 16 bits (so sizeof(char) = sizeof(short) = > sizeof(int) = 1) > 3) the c5x is essentially big endian > > My plan is to change int and unsigned int to int32_t and uint32_t wher...

I'm finding it dificult to get the code to fit within c5x dsp, especially due to the large heap necessary for the huge allocations in nb_encoder_init and nb_decoder_init. Are the people that have this running using additonal external ram? Has anyone experimented with reducing the internal encoder/decoder stack sizes for narrow band... is there a p...

...ot already defined, and then put my own, much > smaller value in config.h. Yeah, I think I'll add an option like that. > For the scratch stack, I replace the fixed values in nb_encoder_init and > nb_decoder_init with constants that I defined in config.h. Jamey Hicks > original C5x patch had some test code in stack_alloc.h to detect working > stack overflow. Maybe something similar could be done to measure the peak > stack usage, enabled by a debug switch. Then, for a space critical > application, it would be easy to measure the stack requirement for a given &g...

Greetings, I've just started porting speex to a TI C5509 DSP. It doesn't look like it's going to be too painful, but there are a couple of quirks about the C5x. 1) chars are 16 bits because memory addresses are for 16bit words 2) ints and short are also 16 bits (so sizeof(char) = sizeof(short) = sizeof(int) = 1) 3) the c5x is essentially big endian My plan is to change int and unsigned int to int32_t and uint32_t where 32 bit ints are needed, such as...

...h the size and scratch/persistent nature of each block. The host > then does the memory allocating, and provides the pointers back to the > application. I'm not familiar with XDAIS, but I would think you could just overload the speex_alloc() and speex_free() functions, right? > The C5x has been another matter altogether. There were some build > issues: > > 1. The C54x compiler does not recognize "long long" and in fact does > not support any 64-bit integer types. For the moment I am using > "double" which maps to a 32-bit floating point on...

...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? fixed_debug.h uses int and short directly, so I know it won't work with the C5x. However, I think fixed_generic.h should work and has all the operators defined as macros anyway, so inlining isn't a problem. > Some optimisation or something is probably possible here to > reduce code size and inline the functions, as by default the C55x compiler > does not seem t...

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,

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,

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

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

...2000 in bits.c. I changed bits.c to set this value only if it was not already defined, and then put my own, much smaller value in config.h. For the scratch stack, I replace the fixed values in nb_encoder_init and nb_decoder_init with constants that I defined in config.h. Jamey Hicks original C5x patch had some test code in stack_alloc.h to detect working stack overflow. Maybe something similar could be done to measure the peak stack usage, enabled by a debug switch. Then, for a space critical application, it would be easy to measure the stack requirement for a given operating mode, a...

...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. Does this command produce *.out file? In other words, isn't need to make a project which includes speex source code in "Code Composer Studio" which is dedicated to c5x (and other TI DSPs)? Please guide me what I must do step by step for using speex on C54? re...

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

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 http://handhelds.or...

> 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