Re: vDSP FFT on PPC
Re: vDSP FFT on PPC
- Subject: Re: vDSP FFT on PPC
- From: Eric Allamanche <email@hidden>
- Date: Sun, 14 Mar 2010 22:57:01 -0700
> Hi there - I'm having some "fun" with the vDSP FFT and I was hoping a guru
> here might be able to point me in another direction...
>
> I've some existing code I've been using a while on an i386 Mac, but now that
> I've acquired a PPC Mac for testing, I'm experiencing intermittent crashes
> (EXC_BAD_ACCESS) during the inverse DFT. The relevant code uses
> vDSP_fft_create(), vDSP_fft_destroy() and vDSP_fft_zop() only; this is
> obviously quite wasteful, but it looks as if I decided not to use
> vDSP_fft_zrop() because I didn't understand the documentation. Looking at it
> now, I still don't! Sorry if I'm being stupid.
>
> The vDSP Programming Guide Introduction states in the "About the vDSP API"
> section that DSPComplex "is used for functions with no suffix" and that
> DSPSplitComplex "is used for functions with a t suffix". However, the
> vDSP_fft_zop(), vDSP_fft_zrop() functions use DSPSplitComplex anyway. Then,
> in the "Using Fourier Transforms -> Data Packing for Real FFTs" section,
> there's a discussion on how real data should be packed as an even-odd array.
> But how is this even-odd array passed as a DSPSplitContext to
> vDSP_fft_zrop()? Am I supposed to set put the data in even-odd order, set
> A.realp=data+0 and A.imagp=data+1 and use a stride of 2?
yes, you can do this using the ctoz function:
vDSP_ctoz((DSPComplex*)data, 2, &A, 1, size/2 ); // where size is the size of your real input vector
You should look at the FFT code examples at http://developer.apple.com/mac/library/documentation/Performance/Conceptual/vDSP_Programming_Guide/SampleCode/SampleCode.html#//apple_ref/doc/uid/TP40005147-CH205-CIAEJIGF for more detailed explanations.
Eric
> Or can I leave the
> data in its original order and pass the array by setting A.realp=data+0,
> A.imagp=data+(dftSize/2) and using a stride of 1?
> Or do I have to create two
> new arrays and use a stride of 1 for some alignment-related reason (seems a
> bit improbable with a DFT size of 2048)?
>
> My code uses a binCount=dftSize/2+1 approach for compatibility with MKL and
> FFTW3 on other platforms, and I'm using "normally" packed std::complex<>
> data, so this is ultimately the form I need the data in for other
> operations. When I use vDSP_fft_zop(), I'm padding out the data to the full
> DFT size (taking conjugates), filling in the DSPSplitContext with
> A.realp=((float*)data) and A.imagp=((float*)data)+1 and using a stride of 2.
> I hope this is right (I think this is what is suggested by the "Specifying
> Address Strides" section of the docs)? My existing code seems to ignore
> vDSP_fft_zop() and computes the DFT/IDFT directly when dftSize<=2 - my
> earlier comments state that "We handle these as special cases as the vDSP
> memory management seems a bit broken". Might this just be an indication that
> I hadn't understood something about DSPSplitComplex?
>
> The crashes are intermittent, so it might also be just that I'm breaching a
> thread safety constraint that I'm not aware of (this is a multithreaded
> app). The application appears to be rock solid on Windows and i386 Mac, and
> the crashes are always in the IDFT operation on PPC Mac.
>
> Any help appreciated...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden