similar to: llcon software using 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

Hello, I'm building packages for Slackware and I've just tried to upgrade Slackware 13.37's CELT package to version 0.11.3, which apparently was released last year, but I've omitted it because it was not announced on the site. Anyway, now that I try build with the following configuration in my SlackBuild script: CFLAGS=$SLKCFLAGS -O2 \ CXXFLAGS=$SLKCFLAGS -O2 \

Hello All, I extended the libNE10 optimizations for float towards mdct_backwards/opus_ifft. I am able to get about 14.26% improvement for Decode use case now on my Beaglebone Black. Please see [1] for measurements. Questions 1. Since this patch needs to go in after Encode [2] patch) should I submit this as patch series? 2. Since Jonathan Lennox posted intrinsics cleanup [3] patch, should

Hi all, This is Linfeng Zhang from Google. I'll work on ARM NEON optimization in the next few months. I'm submitting 2 patches in the following couple of emails, which have the new created celt_fir_neon(). I revised celt_fir_c() to not pass in argument "mem" in Patch 1. If there are concerns to this change, please let me know. Many thanks to your comments. Linfeng Zhang

Hi, For those interested in reading more on CELT, here's another paper that just got accepted. That one focuses on the low-complexity mode and is based on 0.5.1. J.-M. Valin, T. B. Terriberry, G. Maxwell, A Full-Bandwidth Audio Codec with Low Complexity and Very Low Delay, Accepted for EUSIPCO 2009. http://people.xiph.org/~jm/papers/celt_eusipco2009.pdf Cheers, Jean-Marc

Hi, Since our device can only handle the Celt part of Opus (due to a MIPS limitation), we have two questions: 1. Is it possible to via SDP force the remote party to send a specific mode of the 32 different possible modes or to force the remote side to use CELT only? 2. In the reference implementation of Opus it looks like the only way to force the encoder to use CELT only

I am aware of a couple CELT users running the codec across a bit-error channel where corruption takes the form of flipped bits (such as a raw wireless link) rather than a packet-loss channel (like ethernet or an IP network). CELT has been designed to work reasonably well on both kinds of channel. You can turn a bit-error channel into a packet-loss channel by including a CRC across the entire

--- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index f52d2c2..e1a6e9b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,7 +190,7 @@ AC_ARG_ENABLE([rtcd], [enable_rtcd=yes]) AC_ARG_ENABLE([intrinsics], - [AS_HELP_STRING([--disable-intrinsics], [Disable intrinsics optimizations for ARM(float) X86(fixed)])],, +

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 Is there any reason for the second parameter (the 'data' parameter) of celt_decode() not to be a 'const' type? It doesn't look like CELT modifies it and typically the encoded data will be read from a const-buffer of a packet structure. -- Bjoern _________________________________________________________________ More than messages?check out the rest of the Windows

Greetings, I have found that QCONST16(32.f, 10) yields different result (from gcc 4.4.7 ) when the code is compiled for TI C55 or C64 DSPs. gcc - result is 32767 TI compiler result is -32768 (C55 compiler version 4.4.1 and C6x compiler version 7.4.2) Although not in the current code, QCONST32(32.f, 26) results differ in similar fashion. Judging by the use #ifdef TI_C.. in the code base, these

--- celt/fixed_generic.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/celt/fixed_generic.h b/celt/fixed_generic.h index ac67d37..1cfd6d6 100644 --- a/celt/fixed_generic.h +++ b/celt/fixed_generic.h @@ -37,16 +37,32 @@ #define MULT16_16SU(a,b) ((opus_val32)(opus_val16)(a)*(opus_val32)(opus_uint16)(b)) /** 16x32 multiplication, followed by a 16-bit shift right. Results

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

In some conditions (sample rate, frame size, bytes per frame, audio data) the CELT allocator may run out of bits and attempt to place a negative number of pulses in a band. This causes an array underrun and other assorted nastyness. Patch attached. (It should also apply cleanly to 0.5.0 which is also impacted by this bug). -------------- next part -------------- A non-text attachment was

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

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

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:

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

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

I tracked down the bug to an incorrect use of restrict. I would not consider this a compiler bug: we are lying to the optimizer by telling it that a pointer is restrict when in fact it isn't. This can be fixed like so: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..fa5098c 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -276,8 +276,8 @@ void clt_mdct_backward(const mdct_lookup *l,