similar to: Opus implemented on ARM processor

On 3 March 2015 at 21:59, Jonathan Lennox <jonathan at vidyo.com> wrote: > Viswenath, > > My patch should be against the tip, but it?s the very recent tip, > including some changes this past Friday (27 Feb). I mentioned in the IRC > room a problem I discovered in creating my patch, and then later improved > the fix Tim had made for the problem. Where do you get conflicts

Hi Jean-Marc, We're exposing the opus_internal_flags data structure so that we can access the value assigned to prevSignalType. Here's a snippet of our code: error = opus_encoder_get_internal_flags(vad->opus, &internalflags); if (error != OPUS_OK) { return OPUSVAD_OPUS_ERROR; } cur_signal_type = internalflags.prevSignalType; if

Hi Jean-Marc, Thank you for the valuable feedback. You're correct in that we focused on enabling this just for SILK. Because our solutions are focused on voice, we did not explore doing the same in CELT mode, but we can certainly look into the details of analysis.c. Regarding the concern of exposing internals, do you have a specific proposal in mind? We've been sharing this patch with

Hi Peter, There's two main issues with a patch like the one you're proposing. First, the data is only valid when SILK is being used and is essentially undefined in CELT mode. The second issue is that by exposing internals, it makes it impossible to improve these algorithms since it would break API compatibility. I'm not fundamentally against trying to expose some information, but

On 3 March 2015 at 22:17, Jonathan Lennox <jonathan at vidyo.com> wrote: > > On Mar 3, 2015, at 11:08 PM, Viswanath Puttagunta > <viswanath.puttagunta at linaro.org> wrote: > > > > On 3 March 2015 at 21:59, Jonathan Lennox <jonathan at vidyo.com> wrote: >> >> Viswenath, >> >> My patch should be against the tip, but it?s the very recent

Hi Peter, Can you say a little bit more about what you're doing exactly with the information you're exposing and how? unfortunately, I don't have a concrete proposal in mind right now. That's in part because I don't quite understand the use case, but also because it's really hard to expose this kind of information in a way that both avoids breaking application with new

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

Hello Jonathan, Just FYI, I started doing review of your patch and will get back to you in few days. After review, I would like to rebase your patch (as necessary) myself and do some testing.. and re-submit. Regards, Vish On 4 March 2015 at 09:00, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 3 March 2015 at 22:17, Jonathan Lennox <jonathan at

Hi, I'm reaching out because we'd like to contribute back to the project a patch that exposes the signal type of the audio packet when encoding the PCM audio to OPUS. We've found the Opus VAD algorithm to be exceptional in this regard and have written a library that leverages this information for audio end-pointing. Attached is the patch. Please let us know if you'd be willing to

On Mar 3, 2015, at 11:08 PM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 3 March 2015 at 21:59, Jonathan Lennox <jonathan at vidyo.com<mailto:jonathan at vidyo.com>> wrote: Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I

Hi, We are rebasing our audio compression subsystem using OPUS rather than SPEEX. The platform is Android but this piece is written in C code: we need to support armv5/armv7/x86 architectures.... and we use the released opus-1.1beta package from here<http://downloads.xiph.org/releases/opus/opus-1.1-beta.tar.gz>. A lot of our OPUS build system + code to drive the audio compression has been

Hi Mark, Thanks for the feedback. By default CMake is building the static library in debug, to get other things one has to explicit turn it on. To build in release mode for CMake you use the following flag: -DCMAKE_BUILD_TYPE=Release https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html CMAKE_BUILD_TYPE — CMake 3.14.1

It appears that both Opus and amrnb have a function called preemphasis(). In the short term, your options are: 1) Not building statically 2) Renaming that function in the Opus code 3) Renaming that function in the amrnb code I can do the rename for the next version of libopus. Cheers, Jean-Marc On 11/13/2013 05:51 PM, batguano999 wrote: > > Hi > Any idea what's causing these

Hi Any idea what's causing these errors:- /home/user/build/lib/libopencore-amrnb.a(preemph.o): In function `preemphasis': /home/user/build/opencore-amr-0.1.3/amrnb/../opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/src/preemph.cpp:193: multiple definition of `preemphasis' /home/user/build/lib/libopus.a(celt_encoder.o):/home/user/build/opus/celt/celt_encoder.c:455: first defined here

Hi I'm having a problem compiling opus-tools-0.1.7. Version opus-tools-0.1.6 seems to compile OK. I've tried with opus-1.0.3 and opus-1.1-beta. The errors are like this:- "undefined reference to `sqrtf'" etc. This OS is Peppermint Three, similar to Ubuntu 12.04. It uses:- gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Google says it's maybe something to do

I tried the new cmake-based build system to build Opus on Linux and macOS. I'm not familiar with cmake but based on instructions I found online I used it as follows: - mkdir build - cd build - cmake -DCMAKE_INSTALL_PREFIX:PATH=<install-path> .. - make - ctest - make install Although the "make" command completed, it reported that optimizations were disabled:

Hi. I would like to contribute to the project regarding exposing VAD information from opus frame. I think VAD flag is very useful in jitter buffer management. And it can be used at end-point detection for voice recognition, too. As you know, there isn't VAD flag in CELT mode. So, in my proposal all frames are assumed active signal in CELT mode. It works on only single packet. In multiple

Hello Forrest, some years ago i developed a network media player based on a STM32F407ZGT6 (168MHz clock) and opus 1.1. I used just the fixed point code and did no particular optimization on the opus code itself because the performance was already quite good, see figures below. The figures are for real time playback with different frame sizes and various constant bit rates. I didn't play

<style>table.customTableClassName {margin-bottom: 10px;border-collapse: collapse;display: table;}.customTableClassName td, .customTableClassName th {border: 1px solid #ddd;}</style><div id="write-custom-write" tabindex="0" style="font-size: 12px; font-family: 宋体; outline: medium none currentcolor;"><p style="margin:0px;">Dear

On 2013-09-24 5:46 AM, Jean-Marc Valin wrote: > 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? Indeed. The opus-tools build explicitly adds -lm for opusdec and opusenc because they use math