vDSP FFT on PPC
vDSP FFT on PPC
- Subject: vDSP FFT on PPC
- From: "Richard Furse" <email@hidden>
- Date: Sun, 14 Mar 2010 16:25:51 -0000
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? 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...
--Richard
_______________________________________________
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