similar to: Problems compiling with Android NDK

I?ve tried adding support for OPUS_FAST_INT64 to celt/arch.h, and I?ve found that this is indeed comparable in speed, if not a touch faster, than my inline assembly. I?ll submit patches for this. The inline assembly parts of my aarch64 patch set can thus be considered withdrawn. I haven?t yet tried replacing SIG2WORD16 (or silk_ADD_SAT32/silk_SUB_SAT32) with Neon intrinsics. That?s an obvious

Yes, llvm-config. Thanks for the pointer to the build script - that's what I was looking for. -Greg On Thu, Jan 31, 2013 at 5:24 PM, Andrew Hsieh <andrewhsieh at google.com>wrote: > You mean llvm-config? It was deleted after the build. You can modify our > build script build-llvm.sh to get it back. > Clang/llvm-3.2 will be available in the next NDK release. There is no

Hi LLVM Android NDK developers, I was curious how clang was built for this release, but didn't find the llvm-setup executable in the NDK. Can you share how your build was configured here? And I see the Chromium build distributes a separate version of clang that looks to be somewhere beyond the 3.2 release. Has there been any talk of both Android and Chromium sharing the same clang? Or is

Hey, I am trying to build a haskell cross compiler to android by building the glasgow haskell compiler with target=arm-linux-androideabi. It builds, but the executables the compiler produces segfaults on my android device. This is probably not llvm related, but I want to rule that out. I used the llvm version shipped with ubuntu 12.10 for the build. I was wondering if maybe I have to use llvm

cc +andrewhsieh +loganchien On Tue, Nov 13, 2012 at 11:21 PM, Joe Abbey <jabbey at arxan.com> wrote: > Hats off to the Android NDK team! > > Thanks for including me here, but I'd like to clarify that this is all from the really hard work of Andrew Hsieh and Logan Chien, and a few other Android engineers. (I'm actually not working on Android anymore, Andrew and Logan have

Hi flac-dev, When we try to build libFLAC v1.3.1 using the Android NDK, we currently are getting an error in a couple files: ../../third_party/flac/src/libFLAC/md5.c:498:25: error: use of undeclared > identifier 'SIZE_MAX' > if ((size_t)channels > SIZE_MAX / (size_t)bytes_per_sample) > I filed a bug for it on the sourceforge bug tracker:

Thanks, I look forward to seeing what you find out. BTW, I was wondering if you tried replacing the SIG2WORD16 macro using the vqmovns_s32 intrinsic? I'm sure it would be faster than the C code, but in the grand scheme of things it might not make much difference. On 11/13/2015 12:15 PM, Jonathan Lennox wrote: >> On Nov 13, 2015, at 1:51 PM, John Ridges <jridges at masque.com>

Hats off to the Android NDK team! http://developer.android.com/tools/sdk/ndk/index.html Important changes: * Added the Clang 3.1 compiler to the NDK. The GNU Compiler Collection (GCC) 4.6 is still the default, so you must explicitly enable the Clang compiler option as follows: * For ndk-build, export NDK_TOOLCHAIN_VERSION=clang3.1 or add this environment variable setting

Congrats to the team for 0.10.0. It sounds really good in the tests I've done so far. I'm really looking forward to the 1.0 release. One question though: could you explain briefly the difference between VBR and unconstrained VBR? And, in my case, the $64K question: is there any situation where CELT could produce more data than specified by nbCompressedBytes when encoding? Thanks

Hello, I am encountering a strange assertion failure using the LLVM libraries cross-compiled for Android using the Android NDK. I am using the official release of LLVM-2.9. The IR which is causing the assertion failure is the following: define void @__construct_Byte__Integer(i8* nocapture %byteLValue, i32 %integerRValue) inlinehint { entry: %0 = trunc i32 %integerRValue to i8 store i8 %0,

Hi Jean-Marc, I'd just like to put in a vote that I wish you'd left in the high-complexity mode in CELT (with the assumption that it could be conditionally compiled out for the IETF standard codec). It seems like it makes it a more useful standalone codec in Xiph's arsenal, and from my own viewpoint I'm uncertain I'll be able to use the SILK codec because of the patent

Hi Jean-Marc, I was just wondering if maybe you would consider a "blog-like" text file in the codebase where you just jot down your thoughts about why you are making a change, and where you think you are headed. For example, I noticed today that you completely removed the pitch prediction code. It would be nice to know if you did that because you're moving away from using it as

Speex tells me that the decoder is always 5 ms, but it says that the encoder is 5 ms for NB, 8.9375 ms for WB, and 10.90625 ms for UWB. Is there an extra frame of delay in the encoder that isn't otherwise accounted for? John Ridges Jean-Marc Valin wrote: > Quoting John Ridges <jridges at masque.com>: > >> I also need to know the precise delays from Speex but I used

I got the approximation from a Google book: http://books.google.com/books?id=2CAqsF-RebgC&pg=PA385 Page 392, formula (10.33) Using this formula, you're right, hypergeom_gain() would *not* converge to 1 for large x, but would instead be gamma(1.25)/sqrt(sqrt(x)) which would approach zero. Now if the formula for the hypergeometric gain were instead gamma(1.5) * M(-.5;1;-x) / sqrt(x)

By my reckoning the confluent hypergoemetric functions should have the following values: M(-.25;1;-.5) = 1.11433 M(-.25;1;-1) = 1.21088 M(-.25;1;-1.5) = 1.29385 M(-.25;1;-2) = 1.36627 M(-.25;1;-2.5) = 1.43038 M(-.25;1;-3) = 1.48784 M(-.25;1;-3.5) = 1.53988 M(-.25;1;-4) = 1.58747 M(-.25;1;-4.5) = 1.63134 M(-.25;1;-5) = 1.67206 M(-.25;1;-5.5) = 1.71009 M(-.25;1;-6) = 1.74579 M(-.25;1;-6.5) =

Good to know. Thank-you for the test. On 11/10/2015 2:37 PM, Jonathan Lennox wrote: >> On Nov 10, 2015, at 3:45 PM, John Ridges <jridges at masque.com> wrote: >> >> Since you're already set up for benchmarks, I would ask if you could >> benchmark the difference between using and not using the ARM64 inline >> assembly. I believe the original justification

> On Nov 10, 2015, at 3:45 PM, John Ridges <jridges at masque.com> wrote: > > Since you're already set up for benchmarks, I would ask if you could > benchmark the difference between using and not using the ARM64 inline > assembly. I believe the original justification on ARMv7 for the assembly > was the processor's panoply of multiply instructions and their long

Something looks odd without your values (or the doc) because hypergeom_gain() should really approach 1 as x goes to infinity. But in the end, an approximation is probably OK because denoising is anything but an exact science :-) Jean-Marc Quoting John Ridges <jridges at masque.com>: > By my reckoning the confluent hypergoemetric functions should have the > following values: >

It's been a while since I did the maths. M(-.5;1;-x) optimises something else, though it's not too far. I think it may be [M(-.25;1;-x)]^2 (or is it the sqrt?) that is supposed to be there. In any case, if there's a mismatch between the doc and the code, the code is the one likely to be correct. Jean-Marc John Ridges a ?crit : > I got the approximation from a Google book: >

Hi JM, When porting my project to the Mac, I found that the definition for "celt_int16" and "celt_uint16" are wrong for the MacOS X Framework in celt_types.h, and need to be changed to "int16_t" and "u_int16_t" respectively. Just thought you ought to know. John Ridges