Avi Harel

07-26-2016, 09:04 PM

Dear All,

I found an apparent contradiction in the analyze_fft1024.cpp (https://github.com/PaulStoffregen/Audio/blob/master/analyze_fft1024.cpp) code,

I would be much obliged if anyone could resolve this :

On the one hand in the function copy_to_fft_buffer, there's the loop :

for (int i=0; i < AUDIO_BLOCK_SAMPLES; i++) {

*dst++ = *src++; // real sample plus a zero for imaginary

}

and this is called from the update() by

copy_to_fft_buffer(buffer+0x000, blocklist[0]->data);

copy_to_fft_buffer(buffer+0x100, blocklist[1]->data);

copy_to_fft_buffer(buffer+0x200, blocklist[2]->data);

copy_to_fft_buffer(buffer+0x300, blocklist[3]->data);

copy_to_fft_buffer(buffer+0x400, blocklist[4]->data);

copy_to_fft_buffer(buffer+0x500, blocklist[5]->data);

copy_to_fft_buffer(buffer+0x600, blocklist[6]->data);

copy_to_fft_buffer(buffer+0x700, blocklist[7]->data);

since the jumps are in multiples of 256 samples this means

(and please correct me if I am wrong)

that buffer results in alternating blocks of 128 samples and 128 zero samples,

all in all 2048 samples as the size of the buffer.

(btw where is buffer zeroed out in the first place, or how should it be assumed ?)

The problem with this is that in the function apply_window_to_fft_buffer,

which is also called from update, we have :

static void apply_window_to_fft_buffer(void *buffer, const void *window)

{

int16_t *buf = (int16_t *)buffer;

const int16_t *win = (int16_t *)window;;

for (int i=0; i < 1024; i++) {

int32_t val = *buf * *win++;

//*buf = signed_saturate_rshift(val, 16, 15);

*buf = val >> 15;

buf += 2;

}

}

which seems to suggest that the samples held in buffer

actually alternate between samples and zeros, i.e. each sample

is followed by a zero as should be the reasonable thing and

it is also supported in the short documentation line in copy_to_fft_buffer above

which says "real sample plus a zero for imaginary".

I could not find any documentation on arm_cfft_radix4_q15 which explains

what it expects in buffer...

so what is the resolution of this apparent contradiction ?

Thanks in advance, Avi

I found an apparent contradiction in the analyze_fft1024.cpp (https://github.com/PaulStoffregen/Audio/blob/master/analyze_fft1024.cpp) code,

I would be much obliged if anyone could resolve this :

On the one hand in the function copy_to_fft_buffer, there's the loop :

for (int i=0; i < AUDIO_BLOCK_SAMPLES; i++) {

*dst++ = *src++; // real sample plus a zero for imaginary

}

and this is called from the update() by

copy_to_fft_buffer(buffer+0x000, blocklist[0]->data);

copy_to_fft_buffer(buffer+0x100, blocklist[1]->data);

copy_to_fft_buffer(buffer+0x200, blocklist[2]->data);

copy_to_fft_buffer(buffer+0x300, blocklist[3]->data);

copy_to_fft_buffer(buffer+0x400, blocklist[4]->data);

copy_to_fft_buffer(buffer+0x500, blocklist[5]->data);

copy_to_fft_buffer(buffer+0x600, blocklist[6]->data);

copy_to_fft_buffer(buffer+0x700, blocklist[7]->data);

since the jumps are in multiples of 256 samples this means

(and please correct me if I am wrong)

that buffer results in alternating blocks of 128 samples and 128 zero samples,

all in all 2048 samples as the size of the buffer.

(btw where is buffer zeroed out in the first place, or how should it be assumed ?)

The problem with this is that in the function apply_window_to_fft_buffer,

which is also called from update, we have :

static void apply_window_to_fft_buffer(void *buffer, const void *window)

{

int16_t *buf = (int16_t *)buffer;

const int16_t *win = (int16_t *)window;;

for (int i=0; i < 1024; i++) {

int32_t val = *buf * *win++;

//*buf = signed_saturate_rshift(val, 16, 15);

*buf = val >> 15;

buf += 2;

}

}

which seems to suggest that the samples held in buffer

actually alternate between samples and zeros, i.e. each sample

is followed by a zero as should be the reasonable thing and

it is also supported in the short documentation line in copy_to_fft_buffer above

which says "real sample plus a zero for imaginary".

I could not find any documentation on arm_cfft_radix4_q15 which explains

what it expects in buffer...

so what is the resolution of this apparent contradiction ?

Thanks in advance, Avi