Всем добрый день.

Возникло желание и возможность окунутся в мир ARM.

Вот озадачился разработать цифровой микшер на 8 входов и 3 выхода.

Не может ни кто подсказать сколько ресурсов потребуется на реализацию 3 полосного эквалайзера???
Интересует опыт работы, привязки к определенным чипам пока нет...

А почему не FPGA? Нужны же по большому счету только интерфейсы I2S и сумматоры с умножителем на коэффициет. А блок эффектов можно сделать отдельным опциональным, если он вообще нужен. По больщому счету хватит любого мелкого проца для управления и Спартана3. DSP как раз будет проигрывать из-за многопотоковости и отсутствия нужного числа сериальных интерфейсов.

Есть мнение, что фильтр 24го порядка для трехполосного эквалайзера нафиг не нужен. Так что один эквалайзер - не проблема, войдет в мелкий дешевый ARM без вопросов. Но каналов то 8.

к тому же есть мнение, что цифры про 20 мкс и порядки взяты с потолка - у меня 18 ногий дспик 16-битный FIR 32-порядка (окно такое же) считает за 30 мкс. А если в общем, то FIR и IIR одного порядка по вычислительным затратам абсолютно не сравнимы - канонический IIR раза в 3-4 медленнее будет, бо КИХ это простая свертка. Хотя может быть тут в дело вступает факт отсутствие у АРМ аппаратных циклов...
Хороших алгоритмов звукоЦОС дофига и больше - препринты AES и DSPA в сети еще никто не отменял
http://www.stanford.edu/~dattorro/EffectDesignPart1.pdf

Ну а как итог - для такой задачи никакие плис и монстроидальные комплексы из нескольких LPC2K не нужны (если, конечно, цель - продукт, а не изучение армов) - есть заточенные решения, где все это решается штатно. Ссылки дадены:
http://www.wavefrontsemi.com/index.php?id=11,13,0,0,1,0
- 8 моно I2S каналов по входу, столько же по выходу. Ресурсов достаточно для 200-полосного эквалайзера (аппликейшн 8 x 20 полос по ссылке)
SigmaDSP - более новые, более перспективные, более мощные.

Ну я не виноват, что кто-то повелся на дешевую рекламу пик-ов.
Цифры взяты из проверенных библиотек для ARM9E.
Учтите наличие в ARM9E команд 32-х битного умножения и наличие флага насыщения. Это не с бодуна назвали DSP расширениями.
Кто не силен в DSP поясню: когда говорят цифровой фильтр n-го порядка, то имеют ввиду, что у него n умножений.
Соответственно и IIR и FIR n-го порядка должны вычисляться примерно за одинаковое время.

Опять же для боевого применения статьи из EffectDesignPart1.pdf не имеют практической пользы.
Там аналитические формулы не переложенные на язык C-и и целочисленную арифметику.
А топик начался не с того, что человек хочет положить годы жизни на портирование алгоритмов.

С другой стороны у чипов wavefrontsemi одна цель - быть как можно дешевле.
Там нет цели быть как можно проще в разработке и освоении.
Поэтому сорсы у них на ассемблере, а апноты локоничны как вывески на базаре.
Кроме самого DSP движка не менее важен пользовательский интерфейс - клавиатура, индикатор, регуляторы, интерфейсы, сменные носители и т.д.
По любому нужен нормальный процессор для всего приложения.
И выбор ARM-ов в целом правильный.

хватит уже нести бред. Я написал "у меня считает" а не "говорят что". Ваши познания в ЦОС широко известны. Почему, кстати, про float не заговорили?


такие фразы, которые действительно похожи на дешевый пеар, на меня всегда грусть навивают. Какие библиотеки, где ссылки?


ну конечно, наличие флага переполнения, а не аппаратного усечения как у взрослых дяденек, теперь называется DSP расширением. Теперь понятно, почему он такой тормоз.
Скажу по секрету, для звука на переполнение вообще можно в большинстве случаев забить, достаточно оценить устойчивость и использовать, если надо, масштабирующие коэффициенты (для БИХ). Динамический диапазон упадет, но никто не мешает использовать 32 бита.


Только больше никому этого не говорите. Для КИХ это действительно так. Для БИХ порядок определяется количеством полюсов фильтра (а есть еще и нули). Для обычного биквадратного звена (2 порядок) нужно 5 умножений, не считая масштабирующих множителей между звеньями.
Вычисление КИХ - это тупое умножение двух векторов: один - коэффициенты, другой - буфер отчетов. В БИХ есть обратная связь, поэтому собстно алгоритм вычисления для любой арихитектуры заметно усложняется. Другое дело, что для получения сравнимой добротности порядок КИХ должен быть в разы больше. И в этом случае часто уже используют умножение в частотной области.


А готовое решение есть только у спецдевайсов, типа wavefront, spinsemi, AD и пр. Вообще-то этим люди деньги зарабатывают. Если топикстартер хочет по быстрому срубить бабла не врубаясь в частности - ссылки выше.


Там осваивать-то нечего...


С этим согласен

Тут вы уж перегнули
Не надо так грубо провоцировать, от этого желания отвечать по теме не прибавляется. Не пацаны же все-таки.

слив засчитан

Тупо денег не срубишь... все такие тупо специализированы микросхемы ставят китайцы, на рынке их куча (китайских устройств)...

Цель стоит создать качественный продукт...

Нос повернул в сторону ARM так как на них встать дешевле чем на DSP... если не потянут полезу в DSP...

Я бы и на msp430 остался но частота маловата... 16M совсем маловато...

НЕ понимаю каким боком здесь fir iir применить??? я туповат

FIR и IIR это так, условные названия разных систем фильтров.
Эквалайзер делается на фильтрах, 3-х полосный эквалайзер значит нужно 3-и полосовых фильтра.
При этом можно применить как FIR так и IIR фильтры.
В тех дешевках по ссылкам в предыдущих постах применяют для эквалайзера IIR фильтры. Они дают большую добротность при меньших порядках (т.е. меньше умножений надо) но сильнее искажают сигнал.
Но это все мелочи на самом деле, реальная проблема у вас в гибком подключении кодеков.

FPGA вижу тут как единственный вариант наиболее безболезненно решить проблему.

Делаете плату типа такой:
http://aly.ogmis.lt/OpenProjects/ARMUltimator2/ARMU2.htm

Там стоит такой FPGA. Пугаться не надо. Нынче тулсы для разработки такие что за вас все сами сделают.
Открываете в Altium-е редактор схемы для FPGA, накидываете туда сколько надо I2S интерфейсов к кодекам (они там в стандартной палитре) и шинный коммутатор для связи с внешним процом. Ну там еще повозиться с назначением ног FPGA и адресов интерфейсов и все!
Работы для ламера максимум на неделю с учетом чтения мануалов.
Никакого программирования, VHDL и проч.

Чуть продвинетесь в освоении FPGA сможете наваять фильтры какие надо на каждый канал.
Недавно появились хорошие тулсы у Xilinx-а которые фильтр спроектированный в Matlab в диалоговом режиме конвертируют в целочисленную арифметику и экспортируют в проект для FPGA.
Примените FPGA со встроенными умножителями и любые ширпотребные DSP увянут по сравнению с ними. И главное ни строчки кода!

Программа остается только в ARM-е.

Нада посмотреть... может вы и правы... я думал что можно сделать эквалайзер так

Преобразование Фурье - Умножение на коэффициенты - Обратное преобразование Фурье

Кстати, весьма логично.
Ваш способ это просто один из путей вычисление FIR фильтра.
Но выигрыш в быстродействии будет только если умножение на коэффициенты замените на ченить более быстрое, например сдвиги.
Но тут о гибкости уже говорить будет сложно.

Например вычисление FIR 64-го порядка займет на 100 МГц около 100 мкс.
БПФ на те же 64-е компоненты займет 30 мкс, но еще обратный БПФ - 30 мкс и непосредственно умножение коэффициентов - почти тот же FIR но без суммирования.
Еще перед БПФ потребуется наложения окна (еще кучка умножений) чтобы снять искажения вызванные разрывами на краях.

Сколько там вам реально нужно точек БПФ чтобы добиться студийного качества гадать не берусь.

Есть еще возможность применить IIR фильтры оптимизированные для линейной фазовой характеристики (чтоб не искажать сигнал).
Но они черти очень сложно поддаются урезанию коэффициентов до 16 бит.

Возможно надо взять ARM-ы с floatpoint сопроцессором. Здесь будет гибкость абсолютная.
floatpoint сопроцессор можно слепить и в FPGA в том же Altium-е, но они там заведомо медленнее получаются чем встроенные в ARM-ы

Тут вылезает вторая проблема как я говорил с недоступностью инфы по качественным аудиопреобразованиям и их численным характеристикам.
Для тех же аудиопроцессоров от Analog Devices все интересные программные либы идут уже скомпилированные, инфы от них ноль.
И вообщем нет надежд, что использование DSP как-то заметно облегчит конструирование эффектов.
Т.е. тут еще определенный R&D нужен.

Это неправда. Выигрыш будет, и значительный, при увеличении размерности окна. Даже в учебниках об этом пишут:
http://www.dspguide.com/ch18/3.htm
тут другая проблема - при увеличении буфера увеличивается задержка. Для реал-тайм обработки это недопустимо.


в данном случает окно не нужно.


да чо вы заладили, нет этой проблемы. Алгоритмы и их численные характеристики доступны. Можно вообще в AES вступить, в Питере могу даже дать контакты российской секции. 50 баксов в год - и есть доступ к самым последним препринтам. Можно подписаться на мейл-лист dsp-audio - там вообще куча монстров сидит, которые самые крутые аппараты делали. Можно наконец, качать бесплатные препринты с DSPA и сходить на KVRaudio - там довольно много качественных опенсорсных проектов.
На целевую платформу переносить придется самому - а то как же... И вообще - топикстартер хотел микшер с эквалайзером. Тут никаких, собстно, алгоритмов и нет.