Если велосипедить до такой степени, то это уж совсем маразм получается…
Ну и таки да: коль уж реально в uint16_t БПФ так шустро считается, то ДКП должно считаться еще быстрей!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
А не надо изобретать велосипед, он уже есть, даже апноут AN4841 для STM32.
Eddy_Em писал(а):коль уж реально в uint16_t БПФ так шустро считается
проблема не в скорости расчета БПФ, скорость ты можешь поднять увеличив тактовую частоту МК до запредельных, проблема в скорости накопления отсчетов АЦП.
Все упирается в эту формулуСпойлерА вот тебе табличку сделалСпойлер
В_Гц, верхняя граница - это половины частоты дискретизации
Н_Гц рассчитана по верхней формуле
Как видно, Н_Гц зависит от количества отсчетов, а количество отсчетов надо еще набрать с помощью АЦП.
t_АЦП это сколько времени в милли секундах требуется, что бы набрать нужное количество отсчетов.
При t_АЦП = 20мс заметно уже отставание.
А буфер, это в минимальной конфигурации, сколько оперативной памяти требуется.
При uint16_t потребуется в 2 раза больше.
Ну а при float ...
Тут вообще проблемы нет, т.к. на STM32 АЦП молотит так шустро, что не успеешь и буфер обработать, как уже новый "намолотит" ☺
а что это такое?
Дискретное косинусное преобразование. Используется во всяких mpeg'ах для сжатия. Ну это аналогично сжатию в пространстве Фурье, когда мы выкидываем часть ВЧ-компонент, передавая только НЧ. А в JPEG2000 используются пирамиды вейвлетов, там еще интересней: можно картинку хранить почти в несжатом виде, но по сети передача медленная, поэтому сначала пользователь увидит нулевое предложение — верхушку пирамиды, потом, по мере подгрузки остальных "слоев", будет видеть все лучшую и лучшую детализацию.
Применение ДКП в спектральном анализе почти от БПФ не отличается: тоже строим разложение, а потом из него получаем спектр мощности. А т.к. нам фазовая информация нафиг не нужна, можно алгоритм упростить.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Ну, глянь в мануал, какая частота АЦП у STM32F0! Весь доступный уху диапазон - от 20Гц до 10кГц реально охватить, даже тормозить придется - таймером АЦП пинать.Другое дело, что для низов придется делать длиннющие выборки: 20Гц требует хотя бы двух периодов, т.е. 2000 элементов выборки на частоте 20кГц!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
при 20мс уже заметно отставание, а 0,1с в 5 раз медленнее.
+еще расчет БПФ, 2000 отсчетов, +еще расчет для ленты или что там у вас будет, +еще вывод на ленту, хорошо если в 0,5с уложитесь, а то и в 1с.
Dimon456, дык, можно и каждые 20мс сэмплирование делать. В этом случае минимальной частотой будет 100Гц (ладно, пусть 50Гц, но хреново).
Если расчеты и вывод данных успевать делать за те же 20-30мс, то для глаза вообще незаметна задержка будет.
У STM32F0 в 8-битном режиме АЦП успеет чуть ли не за 0.5мкс одно преобразование сделать. Учитывая накладные расходы на DMA, пусть будет 1мкс. Так что, придется заводить таймер, чтобы дергать АЦП каждые 50мкс (для оцифровки до 10кГц). За 20мс накопим 400 значений. Вполне хватит, чтобы сделать 16-полосный эквалайзер от 100Гц до 10кГц.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Dimon456, мне это нафиг не нужно. И я все еще не видел вменяемой реализации БПФ. Ну или ДКП. Я это писать сам не собираюсь.
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
цветомузыка - это не столько всякие там ДПФ/БПФ, сколько ритм и алгоритмы выделения соло-инструмента или голоса. если это не сделано, будет наитупецшая мигалка, на которую не то, что ARM стыдно тратить, но даже и КУ202Н с конденсатором...
спектр большинства музыкальных инструментов едва за 6кГц выходит, голос и того меньше, ритм и до 30 Гц не дотягивает... а вот выделить соло - это задача похлеще БПФ, поскольку далеко не с
всегда самый громкий (или самый мощный по спектру) тон ему соответствует...
так что неверной дорогой идете, товарищи...
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Все эти спектры к цветомузыке имеют весьма косвенное отношение. Как надо, я описал ранее: выделить ведущий инструмент или голос и рисовать ему в такт, а фон задавать по ритму. А у вас просто спектр стгнала, да и тот неэстетичный.
Цветомузыка это эстетика в первую очередь.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
ARV писал(а):Как надо, я описал ранее: выделить ведущий инструмент или голос и рисовать ему в такт, а фон задавать по ритму.
миди содержит готовый список инструментов и в соответствии кодируется.
Вы предлагаете выделить из спектра сигнала этот список инструментов и... Это нужно на каждый инструмент хранить свой цифровой отпечаток.
Только миди имеет 24 канала (включая по меньшей мере 16 мелодичных и 8 ударных каналов), а здесь всего один канал.
О том и речь: смоделировать RC-фильтр и КУ202Н впридачу - это разве достижение?!
Вы просто ритм попробуйте выделить... Увы, фильтр инфранизких частот, хоть это и используют в качестве ритма, это еще далеко не ритм...
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Пиковый детектор, визуально выбросы синхронные с ритмом музыки вполне себе видны.
На кой х он сдался?
А в область инфранизких частот 0.5-4Гц еще умудриться оцифровать надо.
