Not enough dsp api for frequency domain analysis Topic is solved

If you have a simple question and just want an answer.
Post Reply
shaileshwankhede
Experienced Member
Posts: 65
Joined: Fri Dec 02, 2016 1:30 pm

Not enough dsp api for frequency domain analysis

Post by shaileshwankhede »

Hi,

I am using xCORE Array Microphone Kits which is having 7 mics. I am trying to perform cross-correlation of signals on adjacent mics. I am using basic formula:
Corrxy = [F(x)]*.[F(y)]
where * denotes complex conjugate. Now since I couldn't find any straightforward api for complex conjugate calculation, complex vector multiplication without splitting into real and imaginary parts, vector square, absolute of complex vector we need to perform lot of operations. Below are the steps I am following and its taking around 6400us for 512 samples.
I think there should be some simpler and efficient way to do this.

Steps:
1. Fill buffer with samples in time domain (512 samples) to create array dsp_complex_t mic_data[8][512]
2. Perform forward dft on this.
3. Iterate over sample length and extract mic_data into separate real and imaginary parts array.
4. Repeat 2 & 3 for other adjacent mic.
5. Apply dsp_vector_mulv_complex on these new array.
6. Simply create copy of result real and imag parts (for performing square operation in calculation of magnitude of complex vector from 5)
7. Multiply by these copies to calculate Real and Imaginary vectors square.
8. Add Real2 and Imag2 to get Corr2.
9. Get vector means of Corr of adjacent mics like of 1&2, 2&3, 3&4...6&1 (centre 0 omitted).
10. Find index of max mean corr to see which signals are most correlated.

Ohh...This is too much calculation :-( if there are efficient hardware accelerated apis for above bold mentioned, then I guess this would have been much more faster and clean. How can I optimize this or is there any other library?

Thanks,
Shailesh


View Solution
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Hi Shailesh,

There isn't a single API that will work for all different sorts of calls, so sometimes you just have to make your own version.

In your steps, you can remove the places where you 'copy data' that way; by making your own functions that access the data in the right way.

I doubt that this will gain a lot, the lion share of the code is going to be the FFTs?

Maybe a very basic question, but you say that 6400 us is far too long; how fast does it need to go? What sample rate are you running at? A 512 size window at 16000 Hz covers 32 ms, or 16 ms with half overlap?

Cheers,
Henk
shaileshwankhede
Experienced Member
Posts: 65
Joined: Fri Dec 02, 2016 1:30 pm

Post by shaileshwankhede »

Ahh Ok. Now I got point. Currently I have reduced sampling rate to 8 KHz assuming speech signal. But can increase it to 16KHz. Now I am having Filling of buffer and then straightforward processing once buffer full. Processing is blocking buffer filling for around 6.4ms. This means I am missing 1/6th of audio samples every time. I need to put buffer filling and processing as parallel tasks. Then that way I am having enough time (32ms at 16KHz) for processing. Anyway algorithm is working almost perfect.

Thanks,
Shailesh
Post Reply