similar to: Disable SILK/CELT only?

I saw the custom API, but nothing explicitly says "CELT-only" just "custom sample rate and frame size". I'll dig further now that you've pointed me in a direction. Thanks, -a On 7/6/15, 6:18 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I believe what you want is called Opus custom (OPUS_CUSTOM in the > code).

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I believe what you want is called Opus custom (OPUS_CUSTOM in the code). With that you can compile only the contents of the celt/ directory and use it like the old CELT. Jean-Marc On 07/06/2015 06:48 PM, Andrew Lentvorski wrote: > Is there a configuration or compile flag that lets me disable the > SILK portion of the codec and use CELT

--- celt/arch.h | 5 +++++ silk/macros.h | 4 +--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/celt/arch.h b/celt/arch.h index 9f74ddd..670527b 100644 --- a/celt/arch.h +++ b/celt/arch.h @@ -78,6 +78,11 @@ static OPUS_INLINE void _celt_fatal(const char *str, const char *file, int line) #define UADD32(a,b) ((a)+(b)) #define USUB32(a,b) ((a)-(b)) +/* Set this if opus_int64

I need to extract SILK only FIXED POINT code. I have a couple of questions in this regard. 1. Is it enough to enable compile time flag (FIXED_POINT) in the config.h, include silk_fixed library and exclude silk_float in the opus_demo project. I am working in the MSVC framework. Anyone has tried this before? 2. It seems there is no compile time flag to enable SILK only code, the core

Hi, I'd like to know the reasons why CELT supports only signals with sampling frequency in the range of 32-96 kHz. In effect, it can clearly outperform speex at high bitrates, and has potential to be used in high quality voice communications even for 11, 16 and 22 kHz speech signals. It could also compete with SILK codec (to be soon released by Skype). See this page for more specifications

Hi everyone, I've made several posts recently about CELT being "replaced" by the Opus codec ( http://opus-codec.org/ ) and I thought it was time to give an update on what's going on. As many of you know, I've been involved at the IETF on this new Opus codec, which essentially merge (a modified version of) Skype's SILK codec with CELT. This is more than just two codecs

hi, I am porting opus encoder to a low end device with 32K ram, 256K flash and 32MHz arm M3 mcu. But opus seems consume too much. To make it work , what I can think of 1, Only fixed point supported 2, Only mono voice application supported 3, Set complexity to zero 4, Support only one sample rate, like 16KHz 5, Silk mode only or Celt mode only My question is , before

Fixes build failure on platforms with MAY_HAVE_SSE4_1 (but not PRESUME_SSE4_1) with --enable-intrinsics. --- silk/fixed/main_FIX.h | 11 +++++++++++ silk/x86/x86_silk_map.c | 2 ++ 2 files changed, 13 insertions(+) diff --git a/silk/fixed/main_FIX.h b/silk/fixed/main_FIX.h index ffeb4f3..375b5eb 100644 --- a/silk/fixed/main_FIX.h +++ b/silk/fixed/main_FIX.h @@ -97,6 +97,17 @@ void

Fixes build failure on platforms with MAY_HAVE_SSE4_1 (but not PRESUME_SSE4_1) with --enable-intrinsics. --- silk/fixed/main_FIX.h | 11 +++++++++++ silk/x86/x86_silk_map.c | 2 ++ 2 files changed, 13 insertions(+) diff --git a/silk/fixed/main_FIX.h b/silk/fixed/main_FIX.h index ffeb4f3..375b5eb 100644 --- a/silk/fixed/main_FIX.h +++ b/silk/fixed/main_FIX.h @@ -97,6 +97,17 @@ void

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

Hello Joshua, I understand. My main aim to first understand the processing overhead when decisions have to be made for a fixed audio in signal, reduce it so that I can then begin making an update to reduce the memory (on chip flash and RAM) footprint. Thanks Amit On Thu, Dec 31, 2015 at 7:58 PM, Joshua Bowman <silverbacknet at gmail.com> wrote: > Opus will always use whatever mode it

Here are my aarch64 patches rebased to the current tip of Opus master. They're largely the same as my previous patch set, with the addition of the final one (the Neon fixed-point implementation of xcorr_kernel). This replaces Viswanath's Neon fixed-point celt_pitch_xcorr, since xcorr_kernel is used in celt_fir and celt_iir as well. These have been tested for correctness under qemu

From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not

From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not

This sequence of patches provides arm64 support for Opus. Tested on iOS, Android, and Ubuntu 14.04. The patch sequence was written on top of Viswanath Puttagunta's Ne10 patches, but all but the second ("Reorganize pitch_arm.h") should, I think, apply independently of it. It does depends on my previous intrinsics configury reorganization, however. Comments welcome. With this and

As promised, here's a re-send of all my Aarch64 patches, following comments by John Ridges. Note that they actually affect more than just Aarch64 -- other than the ones specifically guarded by AARCH64_NEON defines, the Neon intrinsics all also apply on armv7; and the OPUS_FAST_INT64 patches apply on any 64-bit machine. The patches should largely be independent and independently useful, other

Following Tim's comments, here are my reworked patches for the Neon intrinsic function patches of of my Aarch64 patchset, i.e. replacing patches 5-8 of the v2 series. Patches 1-4 and 9-18 of the old series still apply unmodified. The one new (as opposed to changed) patch is the first one in this series, to add named constants for the ARM architecture variants. There are also some minor code

Is there a particular reason why CELT grabs 100KB of stack immediately? Is that really required or can that be trimmed down some/a lot? -a

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 All, Based on reading the documentation and some online resources, it seems that there are 2 codecs CELT and SILK. However when calling opus_encode* API, it is not clear which of the two are used? Is there a specific mode to be selected to use one or the other? Regards Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: