similar to: NFFT on a Zoo?

I'm trying to get these cleaned up and landed, but I'm running into some trouble with this patch. Using commit a08b29d88e3c (July 21) of Ne10, I'm seeing test failures for 60-point FFTs: nfft=60 inverse=0,snr = -3.312408 ** poor snr: -3.312408 ** nfft=60 inverse=1,snr = -16.079597 ** poor snr: -16.079597 ** All other sizes tested appear to work fine (84 to 140 dB of SNR). This

I have time-series data from a pair of inexpensive self-logging 3-axis accelerometers (http://www.gcdataconcepts.com/xlr8r-1.html). Since I'm not sure of the vibration/shock spectrum I'm measuring, for my initial sensor characterization run the units were mounted together with the sample rate set to the maximum of 640 samples/sec. Unfortunately, at this sample rate there are significant

Hello Timothy, Great to hear from you! Fired up my hardware today and this issue looks like a regression in Ne10 library. The commit in Ne10 [1] that I tested to be working successfully back in May 5b63074db45000f9688460990ee3f5e147d93782 which is the Patch Phil at ARM added to fix the overflow issue in nfft=60 case. After git-bisect, looks like the culprit patch in Ne10 [1] is

Hello Jean-Marc, Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr = 93.537021 nfft=256 inverse=0,snr = 88.353151 nfft=256

Hello Jean-Marc, Yep, that was it.. with your patch, test_unit_mdct passes for all nfft. So, what you do you suggest the next step here is? Regards, Vish On 8 May 2015 at 12:30, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi, > > Can you apply this change to the MDCT test and run it again. See if more > (all) sizes pass. Given the results, I strongly suspect an

Hi, Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. Note that libopus1.1, as extracted from the tar ball, is OK. Specifically, the tests that fail are in celt/tests/test_unit_mdct: nfft=32 inverse=0,snr = 85.341197 nfft=32 inverse=1,snr =

Hi Timothy, Sorry for late reply. I have upstreamed the patch to fix the regression here: https://github.com/projectNe10/Ne10/commit/ee5d856cd9cb8c4a15ace567df4239f4e788d043 I have tested it with Vish's branch: http://git.linaro.org/people/viswanath.puttagunta/opus.git/shortlog/refs/heads/rfcv3_fft_fixed) Both unit test dft and unit test mdct passed on ARM v7/v8, floating point/fixed

Viswanath Puttagunta wrote: > What should we do for power-of-2? I really want to avoid putting > runtime checks if nfft is power of 2 in opus_fft_float_neon. Given the tests that had to be disabled for NE10, I suspect we will not really be able to use it for CUSTOM_MODES, which should be the only time nfft is a power of 2. So I'd suggest just disabling the support when CUSTOM_MODES

> I had the idea of implementing a lot of the operations in FFTs. ( for > example, it is possible to do auto-correlation and FIR filtering using > FFTs.) There are two advantages to this. > 1. It's almost always faster > 2. By swapping fft implementations, it could be easy to recompile for > fixed or floating point versions. No. FFT's require higher precision than

Viswanath Puttagunta wrote: > if OPUS_ARM_NEON_INTR > CELT_ARM_NEON_INTR_OBJ = $(CELT_SOURCES_ARM_NEON_INTR:.c=.lo) \ > - %test_unit_rotation.o %test_unit_mathops.o > -$(CELT_ARM_NEON_INTR_OBJ): CFLAGS += $(OPUS_ARM_NEON_INTR_CPPFLAGS) > + $(CELT_SOURCES_ARM_NE10:.c=.lo) \ > + %test_unit_rotation.o %test_unit_mathops.o \ > +

Hi all, I have already added support for scaled forward non-power-of-2 floating-point FFT: https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9 Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled. By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will scale the output. So we can remove need for one buffer on

This is not the same as the recent thread on a waterfall graph. I'm thinking about the rolling FFT display used in acoustics and other spectrum analysis tasks. Here's an example of a very fancy 3-D waterfall display: http://www.ultimaserial.com/UltimaWaterfall.html I was just wondering if there are any simple hidden-line tools in R that I could use to draw simple waterfall displays.

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Jean-Marc, **Resending.. not sure why subject got removed earlier** Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr =

Hi, Can you apply this change to the MDCT test and run it again. See if more (all) sizes pass. Given the results, I strongly suspect an overflow. Jean-Marc On 08/05/15 01:21 PM, Viswanath Puttagunta wrote: > Hello Jean-Marc, > > Below are the results that show test_unit_dft passes, but > test_unit_mdct fails (only for nfft=480, 960, 1920) > Note: Tested on

On Wed, Feb 5, 2014 at 11:05 AM, Marcello Caramma (mcaramma) <mcaramma at cisco.com> wrote: > Hi, > > Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. > Note that libopus1.1, as extracted from the tar ball, is OK. > >

Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> --- celt/tests/test_unit_dft.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/celt/tests/test_unit_dft.c b/celt/tests/test_unit_dft.c index 5ea10fb..111c249 100644 --- a/celt/tests/test_unit_dft.c +++ b/celt/tests/test_unit_dft.c @@ -177,8 +177,14 @@ int main(int argc,char ** argv)

Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> --- celt/tests/test_unit_dft.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/celt/tests/test_unit_dft.c b/celt/tests/test_unit_dft.c index e17e26f..f08eb65 100644 --- a/celt/tests/test_unit_dft.c +++ b/celt/tests/test_unit_dft.c @@ -177,8 +177,14 @@ int main(int argc,char ** argv)

On Jan 15, 2010, at 10:03 AM, Chris Lattner wrote: > > When/if another target wants this, we could add a ISD::RBIT operation, > it doesn't need to be added at the llvm ir level, Blackfin can add with backwards carry, essentially doing (rbit (add (rbit a), (rbit b))) This is used for FFTs. I wasn't hoping to be able to pattern-match something so complicated.

Hello, I'm building packages for Slackware and I've just tried to upgrade Slackware 13.37's CELT package to version 0.11.3, which apparently was released last year, but I've omitted it because it was not announced on the site. Anyway, now that I try build with the following configuration in my SlackBuild script: CFLAGS=$SLKCFLAGS -O2 \ CXXFLAGS=$SLKCFLAGS -O2 \