Question about copy_to_fft_buffer function in analyze_fft1024.cpp

[egg]

Hi,

Why does the following function use unsigned types (uint16_t and uint32_t) for data that is copied into the buffer, when the buffer (as declared in the header file) uses the signed int16_t type?

// 140312 - PAH - slightly faster copy
static void copy_to_fft_buffer(void *destination, const void *source)
{
	const uint16_t *src = (const uint16_t *)source;
	uint32_t *dst = (uint32_t *)destination;

	for (int i=0; i < AUDIO_BLOCK_SAMPLES; i++) {
		*dst++ = *src++;  // real sample plus a zero for imaginary
	}
}

I understand that the second half of the 32 bit value would hold the imaginary part of the input data, but I don't see why any unsigned types are used in this function. Also, this applies to the 256 point FFT code as well.

 

[el_supremo]

What the routine is doing is copying 128 16-bit numbers (the real portion) and adding a 16-bit zero word after each one - the zero is the imaginary part of the number.
If you specifically copy the integers as signed, you can fall afoul of sign extension, so that copying 0xffff as signed integer might end up with 0xffffffff in the 32-bit result instead of 0xffff0000.
Note that the function actually doesn't care what the type of the source and destination pointers are - they are both declared (void *).

Pete

 

[egg]

Thanks Pete! (I was looking at the history of the Audio repo and noticed that you actually added this part) I definitely have much to learn about C++. I do have another question, though I would understand if it should be moved to its own thread.

Since the arm_cfft_radix4_q15 function used in the FFT code is deprecated (according to arm_math.h), should it eventually be replaced by arm_cfft_q15? I'm guessing it's not a big deal...

Ephraim

 

[el_supremo]

FYI: There are two wee mistakes in my explanation.

copying 0xffff as signed integer might end up with 0xffffffff in the 32-bit result instead of 0xffff0000

This should say:

copying 0xffff as signed integer will end up with 0xffffffff in the 32-bit result instead of 0x0000ffff

Pete
P.S. Sorry, don't know the answer to your question about arm_cfft_q15

 

[egg]

That makes a tiny bit more sense, thanks!

Ephraim