similar to: Memory Size?

Hi everyone, I'm trying to use Opus in an Embedded Project which I'm developing in a STM32F429IIT6 microcontroller. Currently, I'm playing wav files in it. I ported all the files from OpusLib 1.1.4 needed to compile the project, but when I try to create and OpusDecode state, it returns the error -7 (OPUS_ALLOC_FAIL). I'm compiling it with the USE_ALLOCA flag. I also tried to

On 05/06/17 08:28 AM, Ulisses Piassa wrote: > I ported all the files from OpusLib 1.1.4 needed to compile the project, > but when I try to create and OpusDecode state, it returns the error -7 > (OPUS_ALLOC_FAIL). Are you getting OPUS_ALLOC_FAIL on the opus_decoder_init() too or just on opus_decoder_create()? > I'm compiling it with the USE_ALLOCA flag. I also tried to compile it

Hello! First of all Thanks for such a great codec! I have noticed a few smaller inconsistencies in the documentation, which may be confusing: * Encoder related CTLs OPUS_GET_SAMPLE_RATE(x) "Gets the sampling rate the encoder or decoder was initialized with. This simply returns the Fs value passed to opus_encoder_init() or opus_decoder_init()." ---> Is it a generic CTL?

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

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:

Hi all ! I just learned about the Opus codec and would like to try it out on my NRF52 (Cortex-M4) target.   I've been struggling a bit with the "trival_example.c" setup but repeatedly run into "hard fault" crashes when stepping through the code. Firstly; for a "bare bone" configuration, does the following compiler directives make sense ? UDEFS =

Thanks Jean-Marc, I was able to get both encode and decode working the CC3220 device! But for bi-directional communication, I need decode and encode to occur in less time than the frame size I’m sending (20 ms). Currently decode takes 16~22 ms and encode is ~13 ms. What is the best way to try to reduce this time? Also, unsure why encode is taking less time than decode... I've also

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

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:

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

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

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

On 02/23/2018 10:47 AM, Rodriguez, Vince wrote: > Currently decode takes 16~22 ms and encode is ~13 ms. What is the best > way to try to reduce this time? Also, unsure why encode is taking less > time than decode... Tried running a profiler? > I've also noticed if I change my encoder to silk only, I get a Heap > overflow... I have dynamically allocated a heap for the codec,

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

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

I wrote a proof of concept regarding the cpu capabilities runtime detection and choice of optimized function. I follow design which had been discussed on IRC. Also, i notice a little drawback: we must propagate the arch index through functions which don't have codec state as argument. However, if it's look good, i will continue to implement it. Best regards, -- Aur?lien Zanelli