Если поворочивающие коэффициенты 16-разрядные, то на каждом этапе БПФ идет накопление ошибки 1/32768 = 0,00003. За 12 этапов (для 4096 точек) получим уже 0,00037 (= 12 * 0,00003), что эквивалентно использованию 12-битного АЦП вместо 16-битного!
Чтобы обеспечить достойную точность, разрядность коэффициентов должна быть больше 16 разрядов. В этом случае результат умножения превысит 32 разряда, что я и пытаюсь доказать. Вот здесь, для примера, человек пишет "32 bit FFT increases dynamic range by 90 dB". Посмотрите код. Там используются 32-разрядные коэффициенты и специфическое умножение SMULL (Sign Long Multiply) с 64-разрядным результатом.

это если вы 16 бит умножая на 16 бит, пытаетесь на 16 битах остаться.

имея умножитель 32 на 32 бита, вы можете за 1 такт считать в 32 битах, для 4К фурье можно считать в 32-12 = 20 битах величинах, и потеряв 4 бита, останетесь в своих 16 битах...

в 16 битах считать естественно смысла нет...

еще это посмотрите
и это
Мне кажется Вам нужно будет писать функции для работы с большими числами, иначе высокую точность не получите при использовании целочисленной арифметики (мое мнение)

И я о том же. Однако, prig, как я понял, сватал мне именно 64-разрядную арифметику, называя ее почему-то 32-х разрядной. Я было даже повелся , думая человек какую-то военную, не иначе, тайну знает. Да, я и говорю, совет экспертов тут, а не форум электронщиков.

он просто очень плохо объясняет... он предлагал 16 битный вход, и 32 битная арифметика, и
коэффиценты считать в 20 битах для 4К фурье

Ну что, все, кто "ниасилил" фикс. точку, пошли искать процессоры с плавающей?
Ну, а если желание разобраться ещё осталось, могу дать ещё пару подсказок.

- Умножение формата 1.31*1.31 в стандартном "С" реализуется только с использованием целочисленного умножения формата 64*64. Большого смысла в такой реализации нет по причине низкой эффективности. Лучше поискать поддержку фикс. точки (для сигнальников - без проблем) или "прикрутить" её самому.
- Если компилятор "не понимает" формат и "не умеет" выполнять операции с фикс. точкой, простейший и наиболее эффективный путь реализации умножения - ассемблерный код.
Для умножения формата 1.31*1.31 с результатом в формате 1.31 используется целочисленное умножение в формате 32*32 с результатом в формате 64 (на ассемблере - без проблем). Промежуточный 64-битный целочисленный результат нормализуется (сдвиг точки и округление) в 32-битный результат с фикс. точкой.
- Даже если компилятор поддерживает типы с фикс. точкой, рекомендуется реализовать на ассемблере, с использованием промежуточных 64-бит, хотя бы "бабочку" БПФ.

П.С.
Способ реализации умножения 1.31*1.31 с результатом в формате 1.31 не отменяет того, что это 32-битная арифметика.
То же самое касается 32-битного формата с плавающей точкой.



М.б., плохо объясняю. М.б., кое-кто невнимательно читает или не слишком точен в том, что пишет. Предлагал я несколько иное.

Ну или опять кто-то не понятно объяснил
Я имел в виду фикс точка нормированная в 20 бит, промежуточные операции 32 битные...

Ну да, исходные данные, нормированные в 20 бит формата с фикс. точкой. Скажем так. Для 4К, естественно.