search for: ifft

...length(x), by = 4)],4,4,1) # interpolate a sub-sample Warning in rbind(x, array(val, dim = c(n - nx, NCOL(x)))) : number of columns of result is not a multiple of vector length (arg 1) Warning in Fft(postpad(x, N)) * B : longer object length is not a multiple of shorter object length Error in ifft(Fft(postpad(x, N)) * B) : dims [product 36] do not match the length of object [256] Calls: interp -> fftfilt -> fftfiltx -> ifft Execution halted

...gnostic(rec_file, play_file, out_file, tail_length) F=fopen(rec_file,'rb'); rec=fread(F,Inf,'short'); fclose (F); F=fopen(play_file,'rb'); play=fread(F,Inf,'short'); fclose (F); rec = [rec; zeros(1024,1)]; play = [play; zeros(1024,1)]; N = length(rec); corr = real(ifft(fft(rec).*conj(fft(play)))); acorr = real(ifft(fft(play).*conj(fft(play)))); [a,b] = max(corr); if b > N/2 b = b-N; end printf ("Far end to near end delay is %d samples\n", b); if (b > .3*tail_length) printf ('This is too much delay, try delaying the far-end signa...

Hi all, If I use a moving average, it will smooth the choppy time series, but it will lead to lagging... How do I smooth timeseries without the lagging effect? Thanks!

Viswanath Puttagunta wrote: > Can we please have review on RFCv2? We have quite a few optimizations > (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward > etc) that are in my pipeline that depend on this patch series being > accepted. So, trying to make progress on this... On an armv7l board running Ubuntu, you've broken the build with just --enable-intrinsics (without the NE10...

...ntly, FFTWrap.c uses the USE_SMALLFT and USE_KISS_FFT to select between two packages of FFT routines. ] #ifdef USE_SMALLFT ... #elif defined(USE_KISS_FFT) ... #else #error No other FFT implemented #endif My guess is that every DSP and many other processors will have their own specific FFT and iFFT. What method should be used to drop in a DSP specific FFT? Should just use something like this for fftwrap.c? #if defined(__TMS320C55X__) #include "FFT_TI55.h" #endif #ifdef USE_SMALLFT ... #elif defined(USE_KISS_FFT) ... #else // Use FFTWrap_*.h file to supply processor specific...

Hi everyone, I have profiled Opus on AArch64. I just run opus_demo with some pcm files. Following is time proportion of FFT with different bitrate. Bitrate | Time cost by FFT/iFFT 24kb/s | 15% 48kb/s | 15% 96kb/s | 13% Any comment? I want some data close to real application, any suggestion? Thanks, Phil Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20141125/ae6c1c8c/attachment.htm

Hello opus-dev, Can we please have review on RFCv2? We have quite a few optimizations (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward etc) that are in my pipeline that depend on this patch series being accepted. Regards, Vish On 4 February 2015 at 12:21, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > Changes from RFC PATCH v1: > - passin...

...ch also seem to affect PhatNoize). (Note that the LSP problem, when it exists identically in the encoder and decoder will seem to almost disappear). In any case, the new LSP code is committed and should head off all of the above possible problems. As a useful side effect, LPC IIR filters and the iFFT are now completely eliminated from the decode side and decode with current streams is about 10% faster. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/

...t I did was this: Load speex_wb.wav as one large chunk of data. Pad data with as many zeroes as there are samples. Convert to long double. Use one long double FFT for the entire thing. Insert or chop off zeroes so the new length is (input_length)*(sample_target)/(sample_source) Use one long double iFFT for the entire thing. We'll call the FFT and iFFT of this our reference. Then, for each resampler below, I've reported the maximum numerical difference in the time domain(comparing ref[i] with sig[i]) as well as SNR. Since my knowledge of SNR for this is a bit sketchy, it's computed...

On 25 February 2015 at 19:54, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Viswanath Puttagunta wrote: >> >> Can we please have review on RFCv2? We have quite a few optimizations >> (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward >> etc) that are in my pipeline that depend on this patch series being >> accepted. > > > So, trying to make progress on this... > > On an armv7l board running Ubuntu, you've broken the build with just > --...

..., kiss_fft_scalar *in, kiss_fft_scala yp0 += 2; yp1 -= 2; } + // Handle the odd case + if(N4 & 1) + { + kiss_fft_scalar re, im; + kiss_twiddle_scalar t0, t1; + /* We swap real and imag because we're using an FFT instead of an IFFT. */ + re = yp0[1]; + im = yp0[0]; + t0 = t[i]; + t1 = t[N4+i]; + /* We'd scale up by 2 here, but instead it's done when mixing the windows */ + yp0[0] = S_MUL(re,t0) + S_MUL(im,t1); + yp0[1] = S_MUL(re,t1) - S_MUL(im,t0); + }...

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

...yp0 += 2; > yp1 -= 2; > } > + // Handle the odd case > + if(N4 & 1) > + { > + kiss_fft_scalar re, im; > + kiss_twiddle_scalar t0, t1; > + /* We swap real and imag because we're using an FFT instead of > an IFFT. */ > + re = yp0[1]; > + im = yp0[0]; > + t0 = t[i]; > + t1 = t[N4+i]; > + /* We'd scale up by 2 here, but instead it's done when mixing > the windows */ > + yp0[0] = S_MUL(re,t0) + S_MUL(im,t1); > + yp0[1] = S_...

...ect between > two packages of FFT routines. ] > > #ifdef USE_SMALLFT > ... > #elif defined(USE_KISS_FFT) > ... > #else > #error No other FFT implemented > #endif > > My guess is that every DSP and many other processors will have their own > specific FFT and iFFT. What method should be used to drop in a DSP specific > FFT? > Should just use something like this for fftwrap.c? > > #if defined(__TMS320C55X__) > #include "FFT_TI55.h" > #endif > > #ifdef USE_SMALLFT > ... > #elif defined(USE_KISS_FFT) > ... >...

...> I've looked at the code, I think I will do it, as it seems pretty easy: > - I can live with a few emulated floating point operations for gain > computation > - extract gain mantissa and exponent > - multiply fixed-point buffer by mantissa > - offset spectrum exponent before IFFT reconstruction > > What do you think ? It would be even better if you could do it with my pseudofloat macros. It defines a float approximation with 16-bit mantissa and 16-bit exponent. It takes cuts corners all over the place (makes all kind of assumptions), but it's faster than emulati...

...end ['Done'] I've posted the output for the filter-based and block-based resampler at different qualities at http://www.mumble.info/resamp/ The resampling was 96khz => 44.1khz. "chirp.png" is the original (unresampled) "perfect.png" is the result of a FFT/chop/iFFT of the whole file as one. "filter0.png" to "filter10.png" is the "normal" resampler at different quality levels. "block+X.png" is the block-based resampler with X samples overlap (and 960 samples (10ms) base block size). Note that block+0 and block+96 are...

...#zero pad if(nx>nh) { x <- c(x,rep(0, nh-1)) h<-c(h,rep(0,nx-1)) } else { h <- c(h,rep(0, nx-1)) x<-c(x,rep(0,nh-1)) } x <- fft(fft(x) * fft(h), inv = TRUE) Re(x)/length(x) #I am not sure about this, the R IFFT is weird } What "circular" convolution should do is just eliminate the zero-padding: myconvolve2<-function (x,h) { #no padding, circular convolution nx <- length(x) nh <- length(h) x <- fft(fft(x) * fft(h), inv = TRUE) Re(x)/(nx) } I suggest that you create...

...domain. Even then, it's not that > useful. Actually, computing the "power spectrum" for each frame of W shows how large an ammount of the original signal at time offset j the echo canceller thinks should be removed from the current input frame. If you compute W*X for each j and ifft, you'll get the original signal with each frequency component scaled and time-shifted according to what W was (for that j). Anyway, I did some proper testing. I took my headset, bent the microphone arm so it's resting inside the .. uh.. whatever you call that large muffler thing that...

...yp0 += 2; > yp1 -= 2; > } > + // Handle the odd case > + if(N4 & 1) > + { > + kiss_fft_scalar re, im; > + kiss_twiddle_scalar t0, t1; > + /* We swap real and imag because we're using an FFT instead of > an IFFT. */ > + re = yp0[1]; > + im = yp0[0]; > + t0 = t[i]; > + t1 = t[N4+i]; > + /* We'd scale up by 2 here, but instead it's done when mixing > the windows */ > + yp0[0] = S_MUL(re,t0) + S_MUL(im,t1); > + yp0[1] = S_...

...frame of W shows > how large an ammount of the original signal at time offset j the > echo canceller thinks should be removed from the current input frame. Careful when looking at W because of how the real and imaginary parts are packed in the array. > If you compute W*X for each j and ifft, you'll get the > original signal with each frequency component scaled and time-shifted > according to what W was (for that j). Yes, that's the Y/y signal in the code. > Anyway, I did some proper testing. I took my headset, bent the microphone > arm so it's resting insi...