Re: [Audacity-devel] New FFT function

[Philip V. B. <pdv...@vi...>]

Martyn,

Sorry about the confusion.  It is now fixed.  I tracked down the bug last 
night and sent an email about the fix to the list, but for some reason it 
doesn't look like it got relayed on.

The 'crude remap' that I attached to my email a couple days ago checks if 
the incoming data is real (imaginary pointer is NULL) and if so it calls my 
routine instead of continuing on with the existing complex->complex FFT 
function.  Upon return it remaps the output of my function to the expected 
output of the FFT function.  I don't see anywhere in Audacity where it 
actually uses complex->complex (although sometimes both vectors are supplied 
and it just ignores the imaginary part) so all FFT calls could get remapped 
to the new code this way with some performance benefit.

The new functions are optimized for doing the same FFT many times in a row, 
and they process the incoming buffer in-place.  The remap does help, but to 
get the full benefits would require modifying the way the FFT function is 
called, similar to what I did in NoiseRemoval and Equalization.

Phil

--------------------------------------------------
From: "Martyn Shaw" <mar...@go...>
Sent: Wednesday, June 24, 2009 7:21 PM
To: <aud...@li...>
Subject: Re: [Audacity-devel] New FFT function

> Phil
>
> I think you should definitely hold off on any more commits until we
> have the bugs removed from the current ones, and some confidence that
> your FFT is better / at least as good as the current one.  I'm sure
> that a 'Real' FFT is faster than what we have but it's got to work
> properly first.
>
> Please explain your 'crude remap' once that is done.
>
> Thanks for your input!
> Martyn
>
> Philip Van Baren wrote:
>> I submitted new FFT functions, RealFFTf and InverseRealFFTf, and updated
>> the NoiseRemoval and Equalizer effects to use the new functions.  By my
>> benchmarks this gives a better than 2x speedup in NoiseRemoval, and
>> similar improvement in the processing part of Equalizer.
>>
>> I also made a crude remap from FFT() to the new function as proof of
>> concept, and found we can also get some significant improvement in the
>> Plot Spectrum function.  It should also help in the spectrogram plots,
>> but I wasn't sure how to benchmark that.  I didn't submit the crude
>> remap, though, but have attached it to this email in case anyone is
>> interested.
>>
>> Phil
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Are you an open source citizen? Join us for the Open Source Bridge 
>> conference!
>> Portland, OR, June 17-19. Two days of sessions, one day of unconference: 
>> $250.
>> Need another reason to go? 24-hour hacker lounge. Register today!
>> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel