search for: c55xx

I am attempting to port CELT to the TI C5515 DSP. I am compiling/assembling/linking with Code Composer Studio 4. I have enabled the TI_55 specific optimizations in my config.h file per this <http://lists.xiph.org/pipermail/celt-dev/2008-December/000033.html> post. However, I am getting several "undefined symbol" linking errors that do not make sense to me. According to the error

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

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

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

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

...u 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 no assembly optimizations. I have not tried to profile > other rates, but I did run a test at 15kbps, complexity 3, and that was 66 > MIPs. That's from 1.1.12 or svn? > People ask about guidelines for assembly op...

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

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

...Patch is attached. I looked at the patch. Seems mostly OK, though there are some minor issues. First, I don't think it's right to say spx_int_32_t=long except for alpha. This will likely cause problems on Itanium, Power64, SPARC64 and probably x86-64. I suggest either an explicit check for C55xx (and later others) or a test in configure.ac. Also, I'm not sure I get your use of "+#ifdef UNUSED" in the SpeexBits code. Finally, there's a few changes which I think should be removed, like for speex_alloc, speex_warning, ... same as the "#if 0" for wideband and other...

...ologies/rf electronics > and generally interested in everything that has to do with embedded system > running Linux, > though I'm normally doing more of the hardware design stuff ;-) I suggest that you start by looking at 8kbps, complexity 0. I (and others) are running that on a TI C55xx DSP, and it runs a little under 30 MIPs when I last checked, with no assembly optimizations. I have not tried to profile other rates, but I did run a test at 15kbps, complexity 3, and that was 66 MIPs. People ask about guidelines for assembly optimization, and if you do some searching, you wi...

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

...gt; >I looked at the patch. Seems mostly OK, though there are some minor >issues. First, I don't think it's right to say spx_int_32_t=long except >for alpha. This will likely cause problems on Itanium, Power64, SPARC64 >and probably x86-64. I suggest either an explicit check for C55xx (and >later others) or a test in configure.ac. > >Also, I'm not sure I get your use of "+#ifdef UNUSED" in the SpeexBits >code. Finally, there's a few changes which I think should be removed, >like for speex_alloc, speex_warning, ... same as the "#if 0" fo...