DRUID3

Добавлю только, что был приятно удивлен в "матплотлиб" возможностью рисовать график в реальном времени. Правда не знаю стоит ли оно ~1.5 гигамипса ...

Matplotlib... + NumPy...

Так чо? Фазу двигать там просто - частоту много сложнее. Дифур пишет в "кольцо", а по кольцу прыгай куда хошь. Этож гармоника. Кстати у простейшего DDS построенного только на таком принципе нет и не может быть никакого "усечения фазы" - это на заметку тем кто разрабатывает "сверхчистые" синтезаторы.

Точность... Ошибка вычисления... Функция на входе то ожидается аналитическая.

Ну нас то устраивает, но если бы все было так просто стал бы стартер спрашивать? Ну он и в тех трех как бы не совсем целые выдает, но не в этом суть. А в том, что если стартеру нужно очень быстро и сразу в int то быстрее чем на IIR у него не выйдет(ну разве что таблица), но первые значения(переходной процесс) все-равно придется отбрасывать - и перестройка по частоте получается не мгновенная - это да, минус.

...можно... Но я его так для integer и не научился эффективно применять. Это для fix или float скорее. Можно еще дифуром генерить - сопряженные полюса на единичной окружности и вуаля. Я тут недавно ссылку на книгу Роде и Шварца приводил.

Ну а если она не массивом задана? ??

...не в том дело, что куда сложно вделать, а в том что у них совсем разная типизация и там можно наломать дров. Что-бы подключить C-шную библиотеку к пайтону нужен немалый изврат и смысл всей затеи теряется если нет целей просто "ускорить" исполнение скрипта на PC.

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

На скриптовом языке все быстро пишется. Формировать последовательности, проверять валидность алгоритмов - самое то, ГУИ быстренько "накидать". Для тестирования C-кода (без привязки к ЦОС) я так и не пробовал. вообще задачи софт-тестеров и разработчиков DSP-алгоритмов разные. Сам код на C в python просто так не вставишь, нужно немного переделать(а это оверхед). Хотя в NumPy вообще как-то C++ можно заюзать, но я так глубоко не копал. В SciLab можно библиотеки использовать. По-поводу тестирования на железе. Это само собой, но и софт-тесты обязательны - железо мало ли что может показать - от наводок до софтовых но не связанных с алгоритмом ошибок.

хороший сайт... Погуглите - "детектор Тайлоу" или "любительский SDR приемник". Можно было бы напрямую это в контроллере, но у Вас очень высокие частоты, а скорость изменения сигнала намного меньше - оверхед.

Так не бывает. Только для "постоянки"... А нужно оно? Не для всякого реалтайма эти "ксеномаи" нужны. В QEX за прошлый кажется год(нет, вру 2010, №9, 11) - проект любительского SDR с ucLinux на blackfin 537. Реалтайм? Да. Радар можно сделать. В конце концов звук то в реалтайме как-то "линукс" и "виндовс" пишут/играют - понятно, что реалтайм там переносится на контроллер(аудио например) а нереалтаймовым буферированием пренебрегают, но для многих задач это самое то.

...рано. Что-то уж очень большие цифры. Тем более, что мы(Вы) используем RealFFT. По-поводу логарифмирования и корня: sqrt() - это же число в степени 0.5 - а она легким движением руки переносится в показатель степени основания логарифма или просто выносится за логарифм. Потому никакой целочисленный корень не нужен. Кстати, это оффтоп, но у меня есть веские основания полагать почему так развита была теория "кепструмов" для распознавания речи в эпоху малопроизводительных ЭВМ без float - а просто легкое целочисленное вычисление - смотрим дальше по тексту. С корнем разобрались. Теперь с логарифмом. Из его свойств (находящихся в доступном доступе, входящих в школьную программу) видно, что логарифм произведения чисел равен сумме их логарифмов. Тогда нужно определить вес одного пикселя(вычислять меньшие величины нет смысла) узнать какому значению он соответствует и поместить его в таблицу(значение и его логарифм). Получив тот или иной сэмпл, мы узнаем "сколько порций пикселов" в него входит(делением) и складываем их - это и есть наш логарифм. Понятное дело делить лучше не на порции напрямую а "сотни", "десятки", "единицы"(так же и складывать) или "единицы", "пары", "квадры", "хексы" и т.д. Это не я такой умный, а Pilot с "винграда". У него на форуме я такое нашел. Правда тогда я и не допер этот способ, а потом допер и вышла лабуда. А почему лабуда? А потому, что мы ищем не логарифм от 1 до 32768, а логарифм 0.001 до 0.999, а уже эту сетку домножаем на как по x 32768 так и по y.

кратко - выдержат(колонки)... Диапазон DAC-звуковухи и DSP почти совпадают(у звуковухи там регулировать можно)... Напрямую - может сгореть(контроллер).

Они не стандартизированы. В СССР был такой еще стандарт 600 Ом, но сейчас его уже нет. Вход колонок ~1-10kOhm - вполне подойдет.