[begemot]

Литературы по этому вопросу много. Но большинство источников либо написано не очень внятно, либо страдает отсутствием практических примеров, либо недостаточно полно.
Как например вот это: THE SCIENTIST & ENGINEER'S GUIDE TO DIGITAL SIGNAL PROCESSING

Кроме того, даже серьёзные пакеты по расчёту цифровых фильтров иногда содержат ошибки. Я как-то случайно наткнулся на то что пакет по расчёту цифровых фильтров для 12-го Матлаба не правильно считал фазу для одного из типов фильтров.

На мой взгляд вот эта книга Zoran Milivojević "Digital Filter Design" является очень полезным практическим руководством. Каждый тип фильтра рассматривается вместе с примерами расчётов. Очень удобно. Плюс, достаточно подробно. В отличии от книги Analog Devices, где например даже не упоминаются Кайзеровские фильтры. Они, кстати, на самом деле наиболее удобные и универсальные. Так как позволяют получить любое требуемое затухание.

Zoran Milivojević "Digital Filter Design"

•Chapter 1: Basic concepts of digital filtering and types of digital filters
•Chapter 2: FIR filters
•Chapter 3: IIR filters

[БендеровецЪ]

Если начинать почти с нуля, то могу посоветовать вот эту книгу - http://www.amazon.com/Understanding-Digi...0137027419. Чиатется легко, ну и по большей части все есть что-бы въехать в тему.

[s3t]

Спасибо!

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

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


Вот, полистал на тему билинейного преобразования... Хочется более на пальцах, а там формулы, формулы, не особо разписанные на промежуточные точки... Но я полистал, нужно будет вчитываться :)

[begemot]

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

Там из информации почти ничего нет, только скелет. Но такой скелет, что мозги не пудрит,

Создает мнимое ощущение знания

То-то и оно что ощущение мнимое. Это чувство иллюзии только до тех пор, пока не приспичит что-то реально сделать. Причём в некоторых случаях приводит к неверным исходным выводам. Там например вообще не упоминаются Кайзеровские фильтры, а это единственный класс относительно просто реализуемых фильтров, обеспечивающих заданное подавление.
Лайенс в этом смысле вроде и поподробней и посерьёзней. А изложено очень просто. Я тут пролистал на досуге 2ое издание, 3го вроде в сети пока нет. Хотя то-же очень поверхностно. Для развития общей эрудиции.

[bobby_ii]

Вопрос дилетанта: для чего нужен ЦФ - понятно. Есть ли оптимальный (наиболее полно восстанавливающий сигнал) алгоритм для ЦФ? Мне как дилетанту кажется, что таковым должна быть сплайн-интерполяция. "Оконные" ЦФ близки к этому, но ... . Почему применяются оконные фильтры? Применяются какие еще?
ИМХО надо менять архитектуру доставки сигнала до ЦАП. Она на первый взгляд должна быть следующей: программный оверсамплер до 24/96 - 24/192, далее - простенький интерполирующий ЦФ 2х или 4х, реализующий возможности ЦАП. Заодно и ЦАП может работать в постоянном режиме.

[flipper]

В принипе, если вытянуть сигнал до 384, возможно обойтись и вовсе без цф, вполне вероятно, будет лучше, все таки у компа поболе ума для преобразования, чем у ЦФ.

[БендеровецЪ]

Дык, нет же разницы где это делать на самом то деле, синтез фильтра остается аналогичным, на выходе имеем текстовый файлик с коефициентами. А потом он уже подгружается куда надо.
Ну и такой момент что в специально созданых для того микросхемах можно уместить очень и очень большие фильтры. У меня нет уверености что тазик сможет делать больше в реальном времени. Но на тазике канешно будет удобней как минимум отлаживать.

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

[s3t]

Микрушка против компа... комп гораздо мощней тех микрушек, что используются для ЦФ. единственное - ограничение по потоку данных, до 384фс - а это всего 8х оверсэмплинг (для мультибитников катит), ито 384 не всегда доступны, и не всегда их можно использовать (ограничения по частоте битклока - ведь оно 64фс обычно в интерфейсах обычных, а раньше было и 48фс и 32фс для i2s шин - и даже 16фс для паралельной загрузки в 16 битах :))

Поэтому есть некоторые ограничения, куда можно затянуть оверсэмплинг без последствий, для выбрасывания ЦФ.

Коеффициенты - либо действительно широкие аккумуляторы, либо в случае компьютера можно тупо в лоб дабл-флоатом считать :) никаких проблем из-за слишком "плавных" IIR-ов на НЧ, ни DC оффсетов, ни особых искажений из-за кривой последовательности...
Дабл флоат делает фильтры математически достоверными = а значит можно не париться с несовершенствами )

Правда работает медленней... Спасают компиляция и работа в 64бит (20-40% прироста производительности) и переход в многопоточность (в столько раз сколько ядер в системе).
Правда в современных машинках чтоб загрузить проц нужно либо странно-растущие-руки в программировании, либо какие-то странные запросы (например последовательности из FIR фильтров с частоткой от 0.1Гц, многоканально, на 192фс).

[БендеровецЪ]

Я с одной стороны не буду спорить, с другой стороны для филтров используются и огромные специализированые FPGA. Мы даже в среднего размера запихивали нечто очень не маленькое. Я неуверне что на компе это все могло бы считаться в реалтайме без серьезной оптимизации кода. Комп то вобщем вроде то и мощнее, но в среднем не совсем для того предназначен, плюс издержки ОС и высокоуровнего кода.

P.S. Что-то типа 102 каналов с 250ksps до нескольких десятков герц, плюс еще несколько на 1MSPS, плюс еще всякое типа DDS и демодуляторов.

[begemot]

Там уже на уровне драйвера кодека полно обработки. Плюс любая надстройка, типа SRS, Sonic Focus, Beats добавляет кучу всего. Причём чаще всего кодек не имеет особых возможностей для "железной" обработки. Ну там регулировка уровней, иногда простенький фильтр, не более того. Всё остальное - программно.
А когда какая-то система со встроенными говорилками, типа All In One, там обычно очень нехилый эквалайзер на уровне драйвера. Его естественно не видно.
Как это всё работает без особых сбоев и угробивания производительности системы- я не понимаю. Но работает.

[Nick]

Я неуверне что на компе это все могло бы считаться в реалтайме без серьезной оптимизации кода.

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

[flipper]

Году эдак еще в дремучем, когда были в лучше случае пентиум два, мы вешали в Samplitude (32х битный процессинг) на многоканалку в общей сложности обработок типа реверов штук 6-10, и как то вывозило, рилтайм :)

[s3t]

Если без извращений, то оно в лет считается, особенно IIR-ы - там вообще на каждую секцию фильтра достаточно 5 раз перемножить и еще 5 раз сложить (или шесть, не помню )) ).
Т.е. ну 6 MAC-ов, т.е. 6 тактов проца в фпга/дсп, либо 2-3 в процессоре обычном (сильно зависит, но примерно такая вот плата за универсальность).
Итого проц квадкор 3ггц это примерно как дсп 4ггц. Теперь нужно найти дсп 4ггц и посмотреть что он может ))

Вот когда нужно что-то паралельно просчитать - тогда фпга рулит.
Хотя с тем-же успехом можно завести CUDA - оно паралельные таски разрывает в клочья.

Итого - проблем с вычислительными мощностями могут возникать лишь на микроконтроллерах, самых простых ДСП и в извращенных случаях фильтров (длинные ФИР).


ФИР считать не сложно, покуда тапов не много. Если их много - процу становится непосебе.
Что такое много?
На MAC операцию, допустим, требуется 3 такта процессора обычного.
частота среза ФИРа соответствует его длинне, т.е. Fs/n; для 1гц Fs=n;
Количество тактов процессора за секунду = Fs*Fs*3;
т.е. 5.8ггц.
при фс=44100 :)

[БендеровецЪ]

От я вам про одно, вы мне про другое :)
Я не говорю что комп не справится с аудио, я говорю что в fpga влазит тоже очень и очень много, и при оределенных задачах они будут оптимальней и энергоэфективней. Как пример привел один проэкт со 102 каналами где при 250 ksps считаются фильтры с частотами среза порядка десятков герц. Это таки длиные fir , спасает только то что это мультистейдж. Опять же не говорю что тазик не справится с этими 102 каналами, но как минимум надо будет озадачится эфективностью кода.
И вобще это была еще далеко не самая большая fpga семейсва. :)
Было бы интересно глянуть на проэкты обработки сигналов с масивов антен. Там частоты повыше куда, и обработка навернео поинтересней.

[s3t]

Вопросик.

Допустим есть аналоговая передаточная функция H(s).
Я хочу построить по ней ФИР.
Сама функция страшная и извращенная, перестраивать/выковыривать из нее poles/zeroes и т.д. нереально.

Как я вижу процесс.
Берем H(s), т.е. АФЧХ. Натравливаем на нее IFFT, получаем импульсный отклик, соответствующий этой H(s). Импульсный отклик можно в лоб конволвить с чем попало, т.е. это и есть ФИР. Профит.
Возможно, придется заменить "s" на дискретно-временной аналог, сделать prewrap/unwrap частоте и т.д.

Или я что-то и сильно пропустил :)


IFFT это конечно-же извращенье...
Хм... Я с биквадами цифорвыми как-то из direct form по времени легким движением руки нарисовал передаточную функцию.
По идее оно обратимо, т.е. преобразование передаточной функции в discrete time. В последнем соорудить импульсный отклик системы - пять минут работы. Без никаких IFFT.
Хотя, возможно, таки прийдется прибегнуть к IFFT в случае с измеряемым импедансом динамика, а не его аппроксимизации... Хотя реально измерянное можно потом подкинуть в функцию, чтоб она делала вид что она математическая - а на самом деле тупо по табличке результаты возвращала с легким алиазингом.



Еще придется SPICE написать. Вот я себе сэксу то придумал.



UPD:
Видимо можно сделать довольно простым образом.
http://www.audio-perfection.com/forum/thread-96.html
В него засунуть импульс, на выходе снять исковерканный схемкой импульс, и назвать его фир фильтром. :)
Поначалу схемки кроссов можно будет в лтспайсе рисовать, но интерфейс к этому не распологает. Благо можно нетлисты подгружать.

[begemot]

В него засунуть импульс

Длительностью на 1 сэмпл Fs есесьно...

но интерфейс к этому не распологает

Да, там это громоздко. Но зато сам принцип - прозрачный, очевидный и очень наглядный.
В LT наверно стоило бы элементик FIR нарисовать в виде SUB, выводов на 10. И передавать коэффициенты и Fs
И плодить их, плодить,...