similar to: some problem by use libopusenc

Hey Jean-Marc, Does your encoder support ch253/254? Cheers, Drew On Mon, Nov 13, 2017 at 12:33 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi, > > Just to let everyone know that I released libopusenc version 0.1.1. It > does not change the API/ABI compared to 0.1, but fixes a few bad bugs. > You can get it from https://www.opus-codec.org/downloads/ > > For

Hi Drew, On 11/13/2017 03:34 PM, Drew Allen wrote: > Does your encoder support ch253/254? Not at this point. Only families 0 and 1 are supported. I think adding family 2 shouldn't be relatively straightforward, but adding family 3 would require some thought. Cheers, Jean-Marc > Cheers, > Drew > On Mon, Nov 13, 2017 at 12:33 PM Jean-Marc Valin <jmvalin at jmvalin.ca >

Drew Allen wrote: ... > Vancouver was awesome and amazing, btw and I want to be an > ex-pat now. :P Did it rain?

Hi Opus Experts, I am working on a JNI library which depends on libopusenc which in turn depends on libopus. However, during runtime, I encountered a linking error while loading the library: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "opus_projection_encoder_ctl" referenced by "libopusenc.so" Here is how to reproduce the issue: Build procedure

Actually opus-tools-0.2 has the same issue. Sincerely Forrest Zhang -------------- next part -------------- Add "#define FIXED_POINT 1" into the top of resample.c, outputs of resample are all zeros. Actually the data transform is required before/after calling speex_resampler_process_native(). diff -Naupr libopusenc-0.2.1-vanilla/src/resample.c libopusenc-0.2.1/src/resample.c ---

Hi, Just to let everyone know that I released libopusenc version 0.1.1. It does not change the API/ABI compared to 0.1, but fixes a few bad bugs. You can get it from https://www.opus-codec.org/downloads/ For those interested in testing it, there's an experimental patch to make opus-tools use libopusenc for the encoder:

Hi, I have been struggling with this OOM issue and so far nothing has helped. So we are running 10TB archive volume which stores bit more than 7M files. The problem is that due to the way we are managing this archive, we are forced to run daily "full scans" of file system to discover new uncompressed files. I know, i know, this is not optimal solution but it is as it is right now. So

I'm adding support for elf dynamic symbols in yaml2obj/obj2yaml. I'm seeking opinions about how to model dynamic symbols (and symbols in general) in the yaml structure. Currently, symbols in elf are represented by a top level `Symbols` key, within which symbols are grouped by binding type (Global, Weak, Local). The simplest thing to do would be to mirror this structure to a DynamicSymbols

Hi, On Wed, Nov 1, 2017 at 5:32 PM, Amye Scavarda <amye at redhat.com> wrote: > Welcome to an exceptionally busy month for Gluster! > > Gluster Summit > Thanks to all who attended this year's Gluster Summit. As you can see, > conversations are continuing to happen, with notes from the Birds of a > Feather sessions starting to come into the mailing lists. If something

> I wonder why you want to add the new feature to yaml2obj. Maybe, explaining your motivation would help others understand your problem. Thanks for the cue! I am using yaml2obj to generate stub dynamic libraries. On Wed, Nov 1, 2017 at 11:29 AM, Rui Ueyama <ruiu at google.com> wrote: > I don't have a strong opinion on this. yaml2obj was there when I joined to > the project,

I have a to a samba server (4.4.16) on built on Solaris 11 samba pkg. It is a member of an Active directory domain. Users, for some time, have been experiencing long (20 -40 second) delays when browsing to, opening and writing a network share on the server. Attempts to do any of those results in a dialogue box being displayed showing: Contacting server: \\<server-name> \share

Solved by using alloca i8*, i32 2 which the system seems happy enough with, and bitcasting to the actual type for rest of the code after llvm.gcroot. Not entirely sure if this is a terrible workaround or exactly the way gcroot is supposed to be used... On Wed, Nov 1, 2017 at 11:59 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I'm allocating { i8*, i32 } on the

I’m ok with that, but the reason I’m pushing is because there is no clear plan of action. Even if the plan of action is “When X happens, we can enable C++14”, that’s fine too. I just want to know, concretely, what is X. We should either be able to say never or give a reasonable set of conditions that would enable a switch. All I’ve seen though is “it’s hard” which just means I’m going to ask

I'm allocating { i8*, i32 } on the stack, and would like to add this as a GC root, but I'm having trouble figuring this out. This works as expected: declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) define i8* @bar(i8* %x) gc "shadow-stack" { entry: %objptr = alloca i8* call void @llvm.gcroot(i8** %objptr, i8* null) store i8* %x, i8** %objptr %v = load i8*, i8**

As much as I'm not a fan of most XML things, this application of XPath is *inspired*. This would be a great testing/query tool for tests. It would also be a great way to prototype passes. Looking forward to seeing something like this in llvm/tools/ ! Cheers > On 1 Nov 2017, at 04:00, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This is so cool! I once

Hello all, I would like to propose adding the -mprefer-avx256 and -mprefer-avx128 command line flags supported by latest GCC to clang. These flags will be used to limit the vector register size presented by TTI to the vectorizers. The backend will still be able to use wider registers for code written using the instrinsics in x86intrin.h. And the backend will still be able to use AVX512VL

Most command line options in GNU, macOS and MSVC are not just different in terms of notion but different in terms of semantics. For example, MSVC link.exe doesn't have --start-group and --end-group options because their symbol resolution semantics are different than Unix. link.exe on the other hand doesn't have --init or --fini options because that's ELF-only concept. Linker scripts