similar to: tack + heap sizes ?

?? hi ?Jean-Marc, ? thanks for your answer. But still I am struggling to find a reasonable upper limit for the RAM sizes. ? You say we need 4.5/9.0 kB for enc/dec per channel. But are those sizes really independent of any settings, like frame_size, bitrate, complexity, etc. ? ? at least in our configuration I find these requirements:? ?- native stack: < 2.1kB (enc or dec) measured by RealView

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

Hello Thomas and Amit, Thanks for your notice and the detailed decode performance report. I describe the details of my encode/decode test on STM32F407ZG. A. opus version: latest 1.2.1 (TI: opus 1.1.2) B. KEIL 5.23 (TI: ARM compiler tool chain 5.2.7) C. setup the encoder as the below (fs is the sampling frequency) enc = opus_encoder_create(fs, chans, OPUS_APPLICATION_AUDIO, &opus_err);

? There seems to be a memory violation when calling celt_mode_create(48000, 240). ? The function compute_pulse_cache() calls celt_alloc (the second one, bits=celt_alloc()) in order to allocate 343 byte, but it is using about 872 bytes at that location, which will be deleted by the following allocations. ? In this case the following encoder call crashes at first run. ? Sorry, my time is very

Jean-Marc, Thanks for the response and the helpful info. I am trying to get the library to build without using the pseudostack define, and use either VAR_ARRAYS or ALLOC, but it seems the global stack is not defined. Where do can I define this in my example? VR -----Original Message----- From: Jean-Marc Valin [mailto:jmvalin at jmvalin.ca] Sent: Tuesday, February 20, 2018 5:40 PM To:

Hello all, Attached is the initial proposed implementation for ch.mapping 253/3, based on the IETF proposal: https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 A brief overview of the patch, as it is slightly lengthy: After discussion with Jean-Marc, we determined that ch.253/3 will need the demixing matrix as part of the encoder/decoder struct stack and thus will require a new

We are transmitting CELT encoded packages over a lossy channel, where from time to time complete packages do not arrive at the decoder. My questions: 1. What will be the best pattern to be fed into the decoder in order to minimize the audible impact and make best use of internal states from last block (like overlapp-add history etc.) and best blending with next block ? 2. Does this pattern

Thanks for looking over this, Mark! I'm travelling this week but when I'm back I'll address all of your concerns and send,out another patch. :) On Jun 7, 2017 9:56 AM, "Mark Harris" <mark.hsj at gmail.com> wrote: > On Tue, May 30, 2017 at 3:13 PM, Drew Allen <bitllama at google.com> wrote: > > Hello all, > > > > Attached is the initial

Hello everyone, I tried integrating opus middleware on an STM32L4 microcontroller based project. First thing I noticed is the considerable amount of memory allocated by the opus_encoder_create function (nearly 40 kbytes if I recall). After modifying my project's memory setting (mainly heap size adjustments), I could bypass some aspects of this problems. What I'm noticing now is the time

On Thu, 16 Oct 2008, Jean-Marc Valin wrote: > Aymeric Moizard a ?crit : >>> None of that is defined yet, though I'm open to suggestions on how to do >>> the mapping. >> >> CELT/44100 and CELT/48000 >> a=fmtp:105 stereo=on >> >> probably a latency value? > > It would definitely need a frame_size value > >> "CELT"

Hi everyone, I've recently been making various changes to the way the modes work and the supported frame size. On new feature that may be of interest to some is that CELT should soon support changing the frame size dynamically within a stream. By that I mean varying the amount of audio (in time) transmitted at once, not the compressed size -- which has always been variable. That would

On Tue, 14 Oct 2008, Jean-Marc Valin wrote: > Diana Cionoiu a ?crit : >> Hi Jean-Marc, >> >> 1. Why CELT versus Speex? > > There's nearly no overlap between Speex and CELT. CELT is much higher > quality, very low latency, and of course, higher bit-rate than Speex. So > it really depends on the application. > >> 2. What's the RTP payload for CELT,

<style>table.customTableClassName {margin-bottom: 10px;border-collapse: collapse;display: table;}.customTableClassName td, .customTableClassName th {border: 1px solid #ddd;}</style><div id="write-custom-write" tabindex="0" style="font-size: 12px; font-family: 宋体; outline: medium none currentcolor;"><p style="margin:0px;">Dear

Hi, I am a newbe here, so I hope I am not asking something crazy. I was looking on the Celt downloads and I noticed that the latest command line builds were for version 0.6. I know it is still early in development, and that the devs probably don't have time for developing CL versions for everything. since I know nothing about sourcecode and whatnot, I was wondering if there was a fairly simple

Hello, I received feedback from engineers working on NE10 [1] that it would be better to use NE10 [1] for FFT optimizations for opus use cases. However, these FFT patches are currently in review and haven't been integrated into NE10 yet. While the FFT functions in NE10 are getting baked, I wanted to optimize the celt_pitch_xcorr (floating point only) and use it to introduce ARM NEON

Hi, folks, I have an old CELT thing that I'm updating to Opus and I'm trying to get individual pieces upgraded.  My first task is upgrading the CELT encoder to Opus. The old CELT thing treated the L and R channels as independent mono streams, encoded them somehow with CELT to form one bitstream, sent one bitstream across, and then unpacked it manually after the decoder. Can I do that

Hi, I try to work with CELT encoder & decoder in 2 different threads at the same time. So I create/destroy encoder and encode in one thread and create/destroy decoder and decode in other thread. If I didn't protect celt_encoder_create, celt_encode_float and celt_decoder_create, celt_decode_float with CRITICAL_SECTION I get stable error in icwrs32 or ec_byte_write1 (more often) in encoder.

Is this a common warning? The decoder doesn't return an error on it, but I see it a lot in my test application on windows. It is non existent on my linux box. I haven't tried mingw yet. please note that I'm using visual studio 2008 w/the vcproj that Bjoern Rasmussen made for 0.5.2 (w/some file references removed) at the moment and it is giving a lot of C4554 warnings

hi. i am currently adding celt support to netjack. very nice to see a free low-latency codec :) i currently dont require robustness against packet loss, because the sync code of netjack does not handle packet loss very gracefully. how much bandwidth is wasted for this feature ? is it sensible, to have the data downsampled berfore encoding , in order to reduce bandwidth ? i suspect that just

Just to make sure, what's the goal here? Is the goal 1) to have a fast Opus implementation or are you 2) looking for an interesting FPGA implementation project? If 1), then an FPGA is most likely not necessary since Opus is not computationally expensive. If 2), then it depends on the desired size of the project and the desired quality. The simplest encoder possible is indeed simpler than the