similar to: binaries?

Hi All, I am brand new to CELT and have some questions about support on android. 1) When I play the CELT samples at http://www.celt-codec.org/samples/tasl/on my android Gingerbread (2.3.4) phone it works - does it mean that Android already has CELT built it? If yes, what version of the library is it using? 2) Is there any documentation I can refer to for support level on android? - thanks

I was digging around and saw a bunch of different people have created ways of building libopus for android (even I did one back in the CELT days). Is there an official one somewhere that I missed? I even notice this is the Google sources, but it seems to be a touch long in tooth at this point: https://android.googlesource.com/platform/external/libopus/+/android-wear-5.1.1_r1 I am happy to build

Hi all, Just a quick note to let you know that we are currently integrating CELT with our DAB transmission and reception software tools. We plan to have a working demo at the broadcast conference IBC 2009 in September where we have a small booth. We hope to be able to demonstrate a real-time DAB CELT encoder as part our our Live CD based on Ubuntu and GNU/Radio (

Hi, Thank you for a great work. Opus codec works great under many platforms. I have found a small performance issue under iOS platform. If the macro OPUS_HAVE_RTCD is not set, then encoder doesn't use some _neon functions at low bitrates (up to 64k). If the macro is set, then the compiler hits the error at opus/celt/arm/armcpu.c:153 (a function for detection missed). Being compared to Android

Hi, I believe some Neon code doesn't get invoked properly, because all PRESUME macros were set in my build. Probably not all optimized functions are called directly under iOS. Regards, Victor -----Original Message----- From: Jonathan Lennox Sent: Thursday, August 30, 2018 11:59 AM To: Victor Cherepanov Cc: opus at xiph.org Subject: Re: [opus] NEON detection under iOs On iOS, configure

On iOS, configure should define OPUS_ARM_PRESUME_NEON and OPUS_ARM_PRESUME_NEON_INTR if you’re building for armv7, and OPUS_ARM_PRESUME_NEON_INTR for arm64 (since every Apple armv7 CPU has supported Neon, and of course arm64 supports it though the assembler syntax is different). This should be slightly faster than using RTCD, since the Neon functions can be direct calls instead of indirect ones.

--- win32/VS2015/opus.vcxproj | 2 ++ win32/VS2015/opus.vcxproj.filters | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/win32/VS2015/opus.vcxproj b/win32/VS2015/opus.vcxproj index d9aaa03..f55ea37 100644 --- a/win32/VS2015/opus.vcxproj +++ b/win32/VS2015/opus.vcxproj @@ -852,6 +852,7 @@ <ClInclude Include="..\..\celt\vq.h" /> <ClInclude

Hello opus-dev, Can we please have review on RFCv2? We have quite a few optimizations (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward etc) that are in my pipeline that depend on this patch series being accepted. Regards, Vish On 4 February 2015 at 12:21, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > Changes from RFC PATCH v1: > - passing

I too would like to know the status of the opus IP holders. From what I've seen on the CELT and opus lists, it seems that the CELT part of opus is covered by patents from Xiph and Broadcom, and the SILK part of opus is covered by the rest. All of the IP holders except Qualcomm and Huawei have released their patents to the public as far as opus is concerned, and the general consensus from

Hi, On Sat, Jan 28, 2017 at 2:04 AM, Raghavan, Karthik < karthikr at qti.qualcomm.com> wrote: > Hi > > > > I am not sure if this issue has been resolved, but on the latest opus > 1.1.4, > > · I downloaded the tarball, > > · ran ./configure followed by > > · make and then > > · make check > > > > Can you

Hi, Seems like it's not linking with libm. I suspect it has to do with linking statically with libopus.a (is that intended?). Maybe opus-tools relies on the fact that libopus is linked with libm and doesn't explicitly add it? Greg? Jean-Marc On 09/24/2013 06:09 AM, bat guano wrote: > Hi > I'm having a problem compiling opus-tools-0.1.7. > Version opus-tools-0.1.6 seems to

Thanks to Jean-Marc and Tim explaining 'git rebase -i' to me, I've factored my reorganization of the Opus Intrinsics configury into a number of hopefully more comprehensible (and thus more reviewable) pieces. This applies to the current tip of Opus Master in git. Viswanath's Ne10 changes require some slight modification to apply on top of these patches, but nothing major.

Hi Timothy, Appreciate the comprehensive code review. The biggest issue I see is the peak stack usage.... rest looks like fairly straight forward cleanup. Is the peak stack usage a complete blocker in current form? If it is indeed a blocker, would it be acceptable if we can reduce additional buffer requirement from 2 buffers (current) to 1, possibly by moving scaling inside

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

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

On 26/11/15 16:40, Jean-Marc Valin wrote: > Please report any issue you find in this release. Using the new SS4.1 code I see a 30% performance increase in my 7 years old AMD laptop. I compile with this: ./configure --disable-static --enable-intrinsics \ --enable-float-approx "make test" runs fine. Great. When I try to do the same on a server running Ubuntu

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

Is there any consensus on what's the correct fix here? Jean-Marc On 06/11/14 04:26 PM, Cameron Gutman wrote: > Yeah that's the one. > > On Nov 6, 2014 1:23 PM, "Tristan Matthews" <le.businessman at gmail.com > <mailto:le.businessman at gmail.com>> wrote: > > On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman > <aicommander at gmail.com

Hi All, Cortex-M4 is a single issue CPU whereas A8 is dual issue so this is the main reason you are seeing a slow-down, use of NEON I would say is secondary, certainly for CELT. We (ESPICO) have done optimisation work on OPUS v1.1 and have ARM implementations about twice the speed of the 'off the shelf' version. Please contact me directly if you want to discuss further. Cliff

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