Re: vDSP FFT on PPC
Re: vDSP FFT on PPC
- Subject: Re: vDSP FFT on PPC
- From: Brian Willoughby <email@hidden>
- Date: Sun, 14 Mar 2010 15:58:41 -0700
Although vDSP is *very* useful for audio, you're more likely to find
a guru on Apple's Performance Optimization mailing list, where vDSP
and the Accelerate framework are the main topic.
As Ian suggests, you probably have misaligned data. Your
std::complex<> is not created with malloc() I'd assume, so it may not
be aligned. Personally, I don't use the C++ data types in my vDSP
code, so I have not seen the problems you describe, on PPC or ix86.
There may be a #pragma that you can use to instruct the compiler to
align the C++ type.
Brian Willoughby
Sound Consulting
On Mar 14, 2010, at 09:25, Richard Furse wrote:
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.
_______________________________________________
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