Dear All,
I found an apparent contradiction in the 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 :
and this is called from the update() by
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 :
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 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 :
Code:
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
Code:
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 :
Code:
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