similar to: C55xx Linking Error

Jean-marc, I am trying to port CELT to the ti dsp c5515. I counted a problem when I try to call a function: len = celt_encode(enc, in, frame_size, data, bytes_per_packet); I guess that the problem in the stack allocation variable defined in the header file stack_alloc.h. For more info over my platform settings, see the attached files. May be the global_stack variable is not good

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

Gents, My TI C55xx complier is complaining about (in opus_encoder.c, opus_encode()): st->silk_mode.payloadSize_ms = 1000 * frame_size / st->Fs; where .payloadSize_ms is opus_int, frame_size is an int, and Fs is a long. Should one of these be cast differently? Thx, MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

I am having trouble understanding the stack allocation scheme when using a C55xx device. From what I can tell, the GLOBAL_STACK_SIZE is set in arch.h to 100,000 bytes (when using FIXED_POINT), which is then used in the ALLOC_STACK macro found in stack_alloc.h. This macro seems to say, if global_stack==0, then call celt_alloc_scratch, found in os_support.h, which in turn attempts to allocate (using

In order to determine the optimum heap size requirements for my embedded C55xx design, I have used the following to get the encoder and decoder memory requirements: size = opus_encoder_get_size(config.channels); enc = malloc(size); error = opus_encoder_init(enc, config.Fs, config.channels, config.application); size = opus_decoder_get_size(config.channels);

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

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 suggest that you start by looking at 8kbps, complexity 0. Actually, I strongly recommand *against* using complexity 0, unless you're really desperate for a few MIPS. The complexity reduction compared to 1 is small, but the loss in quality can be significant. > I (and others) > are running that on a TI C55xx DSP, and it runs a little under 30 MIPs when > I last checked, with

Hello, I'm trying to use speex for implementing a VoIP demo application using linphone on an embedded system. At the moment I'm not really able to do real time encoding, and thinking about making an assembler port for speex to the AVR32 architecture. The AVR32 is a new hybrid MCU/DSP fixed point processor running at 120Mhz in my application. Does anyone have experiences/info about the

Jean-Mark, Tim, Could either of you expound on the following comment in cwrs.c? /*If _k==0, the following do-while loop will overflow the buffer.*/ ---------------------------------------------------------------- ...because the following do-loop does overflow the buffer when k=126 k=2; do _u[k]=(k<<1)-1; while(++k<len); Thanks, MikeH -------------- next

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

Tony, How is this going? Have you been able to get CELT to run on a TI55xx? I am very interested in the % utilization of the hardware and whether multiple instance of CELT on the same DSP are feasible. I look forward to your findings. MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL:

Opus users, We are developing embedded solutions based on the TI C55xx DSPs. We are considering Opus as a solution for our audio compression algorithm. However, before we invest heavily in code integration we would like to get some idea of the MIPS required. We have experience with CELT v.81 and have seen encode (mono) at ~60MIPS and decode at ~40MIPS. Does anyone have any knowledge of the

> 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'm trying to use speex for implementing a VoIP demo application using > linphone > on an embedded system. At the moment I'm not really able to do real time > encoding, > and thinking about making an assembler port for speex to the AVR32 > architecture. > The AVR32 is a new hybrid MCU/DSP fixed point processor running at 120Mhz > in > my application. >

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