similar to: Little bug in the libspeexdsp resampler

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

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

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 =================================================================== ---

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

Hi Jean-Marc, Just some initial feedback, I've just tried to build svn head using the Visual Studio 2005 compiler, and had the following issues: 1. Missing definition of M_PI if it's undefined (and it is on this platform) 2. In speex_resampler_process_int, the compliler can't determine the value of *in_len and *out_len at compile time and thus determine the size of the x and y

First of all, bufout_len = 320 is correct since that value is the number of stereo samples. Using 640 would be wrong (and no wonder that it crashes). Secondly, "speex_resampler_process_interleaved_float" has a bug that keeps it from working when it is output limited, so if you ever set "buf_len" to any value greater than 1764 the resampler will stop functioning properly

Add a new API that doesn't assume used ring, heads, etc. For now, we keep the old APIs around to make it easier to convert drivers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/vhost.c | 52 ++++++++++++++++++++++++++++++++++--------- drivers/vhost/vhost.h | 17 +++++++++++++- 2 files changed, 58 insertions(+), 11 deletions(-) diff --git

Hello Jean-Marc, thank you for your answer! > I'll look into this. There's basically no overflow prevention for now. > I'll think about how to add that without affecting performance too much > (on CPUs that don't have hardware saturation). I'm open to suggestions :-) I'm not sure if I can really help, but I did a few more tests. Reducing the volume of the input

On Wed, Jun 03, 2020 at 03:58:26PM +0800, Jason Wang wrote: > > On 2020/6/2 ??9:06, Michael S. Tsirkin wrote: > > Add a new API that doesn't assume used ring, heads, etc. > > For now, we keep the old APIs around to make it easier > > to convert drivers. > > > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > --- > >

On 2020/6/2 ??9:06, Michael S. Tsirkin wrote: > Add a new API that doesn't assume used ring, heads, etc. > For now, we keep the old APIs around to make it easier > to convert drivers. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/vhost/vhost.c | 52 ++++++++++++++++++++++++++++++++++--------- > drivers/vhost/vhost.h | 17

On 2020/6/2 ??9:06, Michael S. Tsirkin wrote: > Add a new API that doesn't assume used ring, heads, etc. > For now, we keep the old APIs around to make it easier > to convert drivers. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/vhost/vhost.c | 52 ++++++++++++++++++++++++++++++++++--------- > drivers/vhost/vhost.h | 17

For virtualization, we've developed virtio_ring for efficient communication. This would also work well for userspace-kernel communication, particularly for things like the tun device. By using the same ABI, we can join guests to the host kernel trivially. These patches are fairly alpha; I've seen some network stalls I have to track down and there are some fixmes. Comments welcome!

For virtualization, we've developed virtio_ring for efficient communication. This would also work well for userspace-kernel communication, particularly for things like the tun device. By using the same ABI, we can join guests to the host kernel trivially. These patches are fairly alpha; I've seen some network stalls I have to track down and there are some fixmes. Comments welcome!

What will follow soon are updates to vtpmd, vtpm_manager, xm, xl, mini-os, and new vtpm and vtpm manager stub domains. The first patch I''d like to submit upgrades vtpmd to version 0.7.4 This patch does the following: -add checks to configure to check for cmake (required by berlios 0.7.4) -removes all of the 0.5.1 patches -adds a single patch for 0.7.4 -cleans up the makefile, should

Hello all I using 1.2beta3 on Windows and implementing resampler. Audio signals are being retrieved by Windows Core Audio API (e.g. *IAudioCaptureClient::GetBuffer* <http://msdn.microsoft.com/en-us/library/windows/desktop/dd370859%28v=vs.85%29.aspx>) that are interleaved 32-bit floating point signals (-1.0 - 1.0). Then, speex_resampler_process_interleaved_float returns NaN in the output

Look, how about you start from the testresample.c file? Oh, and you seem to be reading 320 samples at a time and processing 640, so that can't be good (and even beyond that your code is wrong for other reasons). Jean-Marc On 11/6/19 1:56 AM, zhouyuchen at iauto.com wrote: > Hello, > I printed the log, in/out len is not truncated, which means that the > input and output are not

The first four bytes is the length of all data chunks, and the first four bytes of each chunk is the length of compressed chunk data, even when there''s only one chunk, which is the case for inline extents. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- fs/btrfs/snappy.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/snappy.c

Attached is a snapshot of work-in-progress of a FFT based resampler. At the moment it works in floating point only, and only basic quality inspection has been done. Some benchmarks comparing the filter-based resampler at Q3 with the FFT resampler with overlap = in_len / 2, using 20ms chunks of data. (-O3 -ffast-math, FFTW3, gcc 4.3.0 on x86_64) 16=>48: 59us vs 19us 16=>44.1: 204us vs