similar to: resample of libopusenc-0.2.1 outputs all zeros if define FIXED_POINT

.. And a version without the API changes. -------------- next part -------------- Index: libspeex/resample_sse.h =================================================================== --- libspeex/resample_sse.h (revision 0) +++ libspeex/resample_sse.h (revision 0) @@ -0,0 +1,128 @@ +/* Copyright (C) 2002-2008 Jean-Marc Valin + * Copyright (C) 2008 Thorvald Natvig + */ +/** + @file resample_sse.h +

Hi, Here's the (hopefully) final version of the resampler, now always using st->mem as the buffer area. It only allocates buffers on the stack when it's necesarry to convert the output between int and float. -------------- next part -------------- Index: include/speex/speex_resampler.h =================================================================== ---

Need to adjust scale for floating input. diff -NaurbB a/libspeex/resample.c b/libspeex/resample.c --- a/libspeex/resample.c 2013-12-20 17:40:27.326576921 +0500 +++ b/libspeex/resample.c 2013-12-20 17:40:16.918577087 +0500 @@ -915,7 +915,7 @@ if (in) { for(j=0;j<ichunk;++j) #ifdef FIXED_POINT - x[j+st->filt_len-1]=WORD2INT(in[j*istride_save]); +

From: Jyri Sarha <jsarha at ti.com> This bug happens quite often when resampling from a low to a high sample-rate with big enough factor. Also the resampling call has to be limited by the output buffer size and some unused samples needs be left in the input buffer. Sometimes when up-sampling with a big factor the resampling function wants to peek one more sample from the input buffer to

There is a bug in "speex_resampler_process_interleaved_int" and "speex_resampler_process_interleaved_float" in the resampler. It seems that when "speex_resampler_process_int" is called for the first channel, "in_len" is set to the actual number of samples used (when output limited), which you would think would be OK to use for all the subsequent calls

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

From: Jyri Sarha <jsarha at ti.com> Also adds inline asm implementations of WORD2INT(x) macro for fixed and floating point. --- libspeex/resample_neon.h | 101 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 101 insertions(+), 0 deletions(-) diff --git a/libspeex/resample_neon.h b/libspeex/resample_neon.h index ba93e41..e7e981e 100644 --- a/libspeex/resample_neon.h +++

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

Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net> --- libspeexdsp/resample.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libspeexdsp/resample.c b/libspeexdsp/resample.c index e32ca45..a19b997 100644 --- a/libspeexdsp/resample.c +++ b/libspeexdsp/resample.c @@ -85,7 +85,7 @@ static void speex_free (void *ptr) {free(ptr);} #ifdef FIXED_POINT #define

On Tue, Apr 15, 2014 at 12:33 PM, Peter Meerwald <pmeerw at pmeerw.net> wrote: > Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net> > --- > libspeexdsp/resample.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/libspeexdsp/resample.c b/libspeexdsp/resample.c > index e32ca45..a19b997 100644 > ---

I'm using resample.c from speex in my project, and was testing it by processing the same waveform twice, with a reset() call in the middle, as follows: short *input_data = read_waveform_as_linear(infileName, &rate, &num_samples, &num_channels); SpeexResamplerState *state = speex_resampler_init_frac(num_channels, in_rate, out_rate, in_rate, out_rate, quality, &error);

Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampler overflows When you fix/workaround those two, is the encoder/decoder working correctly or are there

Hello :) The attached patch (which is not in any way finished) optimizes the resampler. (For those following the discussions on IRC; this version includes optimizations for both direct and interpolate cases). Using GCC 4.3, x86_64, Valgrind to measure instruction counts, resampling 10 frames of 320 floats at quality 3. Direct was measured with a 16=>48 resampling, and interpolate with a

Hi, I just started to examine the DIV32_16 function (Blackfin ASM version), and wondered why the return value of the function inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable 'res' which is returned by this function is of type 'spx_word32_t'. Is this a trick of optimization or a bug? (Same question for PDIV32_16 and MAX16, too!) best

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

1，you say “libopusenc depends only on libopus.”but 2，so，i add speexdsp source code ， but 3，so，i 。。。 but now，what can i do。i use libopus 1.2 and 1.2beta and 1.1.3 test -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20171101/40680ea1/attachment-0001.html> -------------- next part -------------- A

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?