similar to: MIPs Info Needed

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

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:

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:

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

Gents, Where might I find the Fixed Point switch for the Silk portion of Opus 1.0.1? I have generated a config.h file and added #define FIXED_POINT to my project, but still get FLP compile errors in the Silk files. Thx, MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20120821/f1c2327a/attachment.htm

Jean-Marc, It appears that since testcelt reads a WAVE file from disck and passes the data directly to celt_encode, so that celt_encode's "in" buffer must be expecting little-endian formatted packets. Is this correct? Is there endiness switch somewhere? Thx MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL:

"frame_size = PCM audio in signed 16-bit format (native endian). There must be exactly frame_size samples per channel." Sorry for such a simple request, but could you please clarify the definition of frame_size when using stereo audio channels? When you say "frame_size samples" does this mean that, if my frame_size is defined as 128, there are 64 left samples and 64 right

Gents, "CELT now supports a larger dynamic range, suitable for encoding 24-bit audio (float version only)." I realize this was way back in V6, but is it still true? Thx, MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20111010/d38482b5/attachment-0002.htm

I am trying to get CELT running on a TI 5515 and am having trouble creating a heap large enough to accommodate all of the dynamically created variables. In fact, I would much prefer to have all variables created statically. Could someone give me a short tutorial on what I need to do the create all of the requisite variable statically? Thx, MikeH -------------- next part -------------- An

Tim, et al, I have run into several problems with V0.8.0. I will address them seperately. 1. My compiler is complaining about the following code in celt.c which seems to define metric first as celt_word32, then as celt_word16. Am I mis-interpreting something? ?? VARDECL(celt_word32, metric); ?? ALLOC(metric, len, celt_word16); Thx MikeH -------------- next part -------------- An HTML attachment

Hi, I can see that there has been some effort to compile the SPEEX codec to operate on the TI c54x and c55x DSPs and I am wondering if anyone would be able to update the mailing list with their current MIPs and Memory resource requirements for their c54x and/or c55x compilation? The only estimate I was able to find in the mailing list archive was 42MIPs but I'm not sure if this is an

John, > I can see that there has been some effort to compile the SPEEX codec to operate on the > TI c54x and c55x DSPs and I am wondering if anyone would be able to update the > mailing list with their current MIPs and Memory resource requirements for their c54x > and/or c55x compilation? The only estimate I was able to find in the mailing list archive > was 42MIPs but I'm

Gents, In Version 8.1, QCONST16 is defined as follows in arch.h within the FLOATING_POINT section: #define QCONST16(x,bits) (x) However, in both celt.c and quant_bands.c, QCONST16 is referenced without a conditional FLOATING_POINT define. So when I compile as FIXED_POINT I get an "undefined identifier" for QCONST16. Am I doing something wrong? Thx, MikeH

Jean-Marc, Can you give us some insight into the meaning and usage of #define SMALL_FOOTPRINT that appears in cwrs.c? Thx MikeH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100630/6edffd7c/attachment-0002.htm

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

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, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already