similar to: STATIC_MODES, fft and prob members

Hi guys, I'm currently working on a CELT implementation for FMOD, and one of the things we want to do is have all memory required allocated beforehand. This is before we have any information about what sounds will be played. We would like to create all of our CELTDecode instances up front. Because celt_mode_create() requires a sample rate and number of channels passed in, this

I did a download of 0.7.1 sources and saw that fmod was compiling with --enable-static-modes, I decided to try it, but it fails to compile static_modes.c because it doesn't exist. Is that an external dependency? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100302/6e716591/attachment-0002.htm

Hi I noticed a crash issue when I passed the following values: celt_mode_create(96000, 258, &e); CELTMode->mdct.kfft[0] is not initialized after calling?clt_mdct_init() and when?celt_mode_destroy() is called it tries to dereference this value in kiss_fft_free(). -- Bjoern Here's the callstack: !kiss_fft_free(const kiss_fft_state * cfg=0x00000000) ?Line 650 + 0x3 bytes

Hi everyone, I've just changed the API for CELT, but at least there's a good reason for that. It's now possible to use the same mode data for both mono and stereo. So here's the change: - The celt_mode_create() function has a "channels" parameter - The celt_encode_create() and celt_decoder_create() functions now have an additional "channels" parameter. - I

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 all, I'm trying to build the celt package on the Texas TMS320VC5510 DSK. I think there are some #define for it in the code, but I'm doing something wrong. Is there any documentation about it? So far I'm building with the TI_C5X_ASM;CONFIG_TI_C55X #define. Any help? Thank you. Giovanni

Uses NEON optimized fixed point fft routines in NE10 library Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> Signed-off-by: Jonathan Lennox <jonathan at vidyo.com> --- Makefile.am | 12 +- celt/arm/arm_celt_map.c | 46 ++-- celt/arm/celt_ne10_fft.c | 98 +++++---- celt/arm/fft_arm.h |

Optimize opus encode (float only) usecase using ARM NE10 library. Mainly effects opus_fft and ctl_mdct_forward and related functions. This optimization can be used for ARM CPUs that have NEON VFP unit. This patch only enables optimizations for ARMv7. Official ARM NE10 library page available at http://projectne10.github.io/Ne10/ To enable this optimization, use --enable-intrinsics

Hi All, Would it be possible to encode n channels with the CELT api? I can't find a negative or positive in the CELT docs; all I could find is c a check on the nr of channels in wav_io.c in the CELT tools. No clear insight on wheter or not the channels parameter in celt_mode_create can be > 2. Answers on the list were (thanks!): - Sure, You just encode each channel and then store the

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

? 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

I seem to be having trouble creating correct modes for a 44100 samplerate. In reading the header file it says an even value from 64 to 512 I believe (going off memory) for the frame_rate but celt_mode_create returns a null mode. I can get it all working if I use 48000 with 480 frame_rate. I guess in short what is the best way to calculate the optimal mode for latency. Thanks Mike -- Sent

Hi, I am looking into fixed-point code of the CELT decoder for real-time application. Here are some questions.. [1] array, window[] The array, window[] is being initialized from a function below in modes.c. This array is being initialized differently for the decoder, depending on frame size and sampling freq. of the bitstream .. Could you provide us with fixed-point code for initialization of

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work

Changes from RFC PATCH v2 - fixed compile issue when just compiling for --enable-intrinsics for ARMv7 without NE10 - Notes for NE10: - All compile/link warnings are now in upstream NE10 - Only patch pending upstream in NE10 is the one that needs to add -funsafe-math-optimizations for ARMv7 targets. - Phil Wang @ ARM is working on getting this fixed. - Note that even without

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You

Optimize opus encode (float only) usecase using ARM NE10 library. Mainly effects opus_fft and ctl_mdct_forward and related functions. This optimization can be used for ARM CPUs that have NEON VFP unit. This patch only enables optimizations for ARMv7. Official ARM NE10 library page available at http://projectne10.github.io/Ne10/ To enable this optimization, use --enable-intrinsics