similar to: SSE Resampler

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > Alexander Chemeris wrote: > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > > > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > > > results are delayed

From: Thorvald Natvig <slicer at users.sourceforge.net> Some optimizing compilers miscompile the current SSE optimizations when full optimizations are enabled. By using output value pointer instead of a return value, we can bypass this misbehaviour. --- libspeex/resample.c | 8 ++++---- libspeex/resample_sse.h | 24 ++++++++---------------- 2 files changed, 12 insertions(+), 20

Alexander Chemeris wrote: > Hi, > > Here are some questions from user point of view. :) > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, >> and there aren't any obvious artifacts. I also did a 16=>16 test, and the >> results are delayed by 10ms

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

Hi, Here are some questions from user point of view. :) On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > results are delayed by 10ms and within +/- 1 (basically, rounding errors > from the FFT). Do

>> Yes, I plan to use it in a VoIP environment if I can get latency reduced to >> an acceptable level :) >> The latency depends directly on the overlap parameter, which also controls >> the quality. Higher quality => higher latency. You could set the overlap to >> 0, but that would give you some nasty artifacts. >> You can also resample with smaller block

On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > > > Yes, I plan to use it in a VoIP environment if I can get latency reduced to > > > an acceptable level :) > > > The latency depends directly on the overlap parameter, which also controls > > > the quality. Higher quality => higher latency. You could set the overlap to > > > 0,

Ok. I did some quality tests. First off; never do quality tests with ints. I had serious problems interpreting my results until it dawned on me that the signal differences were just 0 or 1. So, after a lot of scratching my head, these are done comparing the result from the _float versions (which is how both resamplers work internally anyway). What I did was this: Load speex_wb.wav as one

Hi, For transforming stereo to mono, averaging is fine and that's what everybody does. For sampling rate conversion, it's another matter (too long for this email) and you should read a bit about it a perhaps grab a library that does that. As for echo cancellation, it will be less complex (and as good) on a (cleanly) down-sampled signal (and certainly not on stereo). Jean-Marc Le mardi

Hi, Here's an updated resampler patch against current SVN. It includes SSE and SSE2 optimizations (the latter if included by _USE_SSE2). Best regards, Thorvald -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: speex-resampler-update.diff Url: http://lists.xiph.org/pipermail/speex-dev/attachments/20080426/e055077f/attachment-0001.txt

Jean-Marc Valin wrote: >> I recently found a .. weird bug on Win32 SSE with GCC 4.2.1. >> >> In libspeex/cb_search_sse.h, the following union is used: >> >> union { >> float __a[4]; >> __m128 __v; >> } __u; >> >> For some odd reason, this particular version of GCC will not 16-byte >> align the union. IE; the alignment

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

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

Ok, this is slightly offtopic, but relates to the quality of input for speex :) I'm working on echo cancellation by means of sampling the wave mix of the sound card as well as the microphone. I originally had two sound cards, which had some synchronization problems (now solved, more or less), but I have also discovered a much better solution using ASIO 2.0, which enables me to sample

Duane Storey a ?crit : > Actually, it might just be an OS "feature".. On most linux and mac > platforms, the memory managers align memory on proper boundaries -- this > doesn't occur on most versions of windows. I don't have all the code in > front of me, but it's possible that it's simply a side effect of windows not > aligning the memory, and an

On 8/23/07, Thorvald Natvig <speex@natvig.com> wrote: > Jean-Marc Valin wrote: > > Duane Storey a ?crit : > >> Actually, it might just be an OS "feature".. On most linux and mac > >> platforms, the memory managers align memory on proper boundaries -- this > >> doesn't occur on most versions of windows. I don't have all the code in >

Spam detection software, running on the system "mix.hive.no", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I recently found a .. weird bug on Win32 SSE with GCC

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

Actually, it might just be an OS "feature".. On most linux and mac platforms, the memory managers align memory on proper boundaries -- this doesn't occur on most versions of windows. I don't have all the code in front of me, but it's possible that it's simply a side effect of windows not aligning the memory, and an implicit assumption in the speex code that it will have