Anybody has experience with voice recognition? I am looking for some code library and examples for AVR. All ideas are welcome. Thanks.

Ну да, так тебе все и выложили, и еще в исходниках. Ты бы еще на арифмометре сделал.

Key word - FFT.

ага, еще и фантастику почитать посоветуйте...с фурье человек далеко уйдет...

Ну а как иначе?
С фурье все достаточно просто. Прощелкали спектр, сравнили со спектром эталона, получили 20 или более % подобия - распознали.

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

А зачем? Уже отменили корреляцию во временнОй области? И еще, а что Вы влаживаете в слова 20% подобия? Это очень мало, между прочим...

Ну а уж если говорить о быстрых методах то быстрое вейвлет преобразование побыстрее будет(если это БВП по Добеши)...

Ой, ну автор насмешил! На PC эта хрень толком не работает, а он на АВР-ке собрался...


Речь - это не DTMF, таким наскоком ее не взять. Люди разные, голоса разные, а говорят одно и то же - фурье ничем не поможет. Да даже один и тот же голос, в разном настроении и с разной громкостью даст разные спектры.
Читайте про цифровую обработку речи. Мне, когда ее почитал, чуть не вывихнув мозги с кепстрами, стало понятно - ловить тут нечего.

М.б. и есть чего, но уж только не на AVR. Хотя если в оффлайн...

Слова состоят из звуков, звуки имеют свой спектр (спектр может быть сдвинут, но картина в общем одинаковая, анализировать надо производную спектра).
У меня есть рабочая программа на базе FFT и анализа спектра, которая реально распознает речь! Она опровергает ваше опасение насчет "не поможет" - поможет еще как. Анализ спектра позволяет достаточно точно выделить звуки, основная сложность в этой задаче это определить границы между звуками, но и тут если не рассматривать все случаи жизни, а принять фиксированный интервал выборки в 10ms и по ним шлепать, то тоже проблем нет.


А как же голосовой набор в телефонах? Ведь это распознавание речи и старенький Samsung N100 если не ошибаюсь, имея на борту скромный LPC ARM успешно справлялся этой задачкой. Эрики старые тоже. Ларчик на самом деле просто открывается, просто видать PC программеры - тупые (или ставят перед собой очень необъятную задачу - не только распознать но и понять ).

PS: Кстати для DTMF детекта FFT избыточно.


Это зависит от метода сравнения. В моем случае 20% - это много.
Грубо не вдаваясь в детали - представим, что спектр входного сигнала отмасштабирован так, что интеграл разности спекторв входного сигнала и эталонного на отрезке от 0 до Fd будет минимальным. Полное совпадение - когда интеграл равен 0. Полное несовпадение - равен X.
20% подобия соотв. - 0.8*X.

А чем Вам AVR не подходит? Фигасе 20Мипс уже "не производительность" , Куда катится этот мир?
Для сомневающихся- готовый проект, читайте тут например:
http://instruct1.cit.cornell.edu/courses/e...L362/index.html

ну с этого готового проекта я как-то начинал... результат впечатляюще отстойный. Даже в их рабочих исходниках косяков немерянно. На авр не добиться серъезного уровня.

Ну на вкус и цвет...
Кому и СТАРТ СТОП достаточно а кому нужно скоротать вечер в философской беседе с контроллером на тему "bit | ~bit"

PS Сорри за оффтоп

Это восьмибитные мипсы. Т.е. когда нормальный DSP _за те же деньги_ будет делать 2000 бабочек в uS, AVR едва ли справится с одной. Кроме того нужно где-то хранить фонемы и слова, что для AVR тоже малореально, в условиях реалтайм.
Хотя я с Вами сразу же соглашусь, при условии, что покажете работающий пример хотя бы на 20 элементарных команд. Надеюсь, на распознавание всего языка (хотя бы 20 тысяч слов) на AVR Вы не претендуете.



Баловался я когда-то с Siemens S45. Не знаю, какой там проц и какой был применен алгоритм, но распознование команд было отвратительно - нужно было сделать десяток попыток, чтобы произнести команду так же, как она была записана. Такой футбол нам не нужен(с)

а что скажете по этому поводу: http://qrx.narod.ru/avt/mgv_gu.htm ? по-моему, ПИК в 4 раза менее производительный контроллер, если сравнивать с AVR той же тактовой частоты... и, как я понимаю, пахает - не жужжит...

Ага... Чернила для восьмого класса. Мы тут выясняли соотношение AVR'овских и ARM'овских мипсов. Примерно в два раза. Если сравнивать с BF - то в 4 раза.



Ну-ка, огласите нормальный DSP за 1-2 бакса?



Не знаю, не знаю. На Осле (SL45) вполне вменяемо работало голосовое управление. Проц там, кстати, C166. Про алгоритм - не скажу, не разбирался. При желании - могу посмотреть, благо idb-файл не потерялся, место, где смотреть, примерно знаю...


Прикольно Интересно, как оно в живую, а не в описании?

Чего-чего ? 200MHz ARM быстрее 20MHz AVR в два раза ? Или медленнее в два раза ? Короче, хочу вашей травы.


Извините, но и AVR будет не 2 бакса, поскольку в 8Ка только команда "да" и войдет, как в примере по ссылке выше.


Я думаю, алгоритм был один и тот же. Будем считать, что у меня голос неправильный.

Где я такое утверждал?

Мы тут вроде "восьмибитные" мипсы с "тридцатидвухбитными" сравниваем. При одинаковой тактовой частоте производительность AVR примерно в 2 раза хуже производительности ARM (сравнивались сборки моего JPEG-кодера, вполне для обсуждаемой задачи можно ориентироваться, чем не ЦОС?).

Так что Ваша фраза про 20 и 200 МГц - это последствия употребления травы Вами, а не мной



Смотря как хранить. Никогда про вокодеры не слышали? Очень близкая тематика.


После травы?

Вообще, я с 16-битными операндами сравнивал. Бабочка с 32-битными операндами на AVR займет еще (гораздо) больше времени, чем с 16-битными. Тогда как DSP(не ARM), как я понимаю, сделает ее в течение одной команды.


Ога, хотите сравнивать запор на максимальной скорости с мерсом на первой передаче ? И какой в этом практический смысл ? Наверное, сказать, что мерс ездит в два раза медленнее запора ?

Да ну? Откуда тут теперь взялись "16-битные операнды"??? Вообще-то сначала было такой вопрос:


И Вы ответили, что


На что я и объяснил разницу между чернилами "восьмибитными" и "тридцатидвухбитными" мипсами.

Остальное все, про мерсы с запорами, траву - это Ваша фантазия.

Вы же вроде не Доктор, а пример стиля ведения дискуссии берете у него. Зачем? Это плохой пример для подражания.

Потому что для бабочек нужна плавающая точка. И чтобы ее эмулировать в целочисленной нужно хотя бы пару байт, иначе получим не вычисления, а ацстой.
зы: против 32-битных операндов я не возражаю. Но 32-битный реалтайм для AVR - это уже смертельно.


Да нет же, фантазия - сравнивать (практически одинаковое) число тактов на команду у камней с тактовой, различающейся на порядок, и разрядностью в четыре раза. Я уж не буду повторяться про соотношение AVR и DSP с конвейером и восьмиядерным АЛУ.


Возражаю. Не знаю, кто Доктор, поэтому стиль у меня свой. Порою описывается как "на глупые вопросы - глупые ответы".

Это ещё что за фантазии? Чем докажете?

Прошу простить джентльмены, что прерываю вашу высокоучёную беседу(:-), заинтересовало сравнение авр с арм

Неужто 8-битный авр и 32-битный арм различается всего в два раза? Что-то мне сомнительно, хотя Rst7 вроде можно доверять, э?(:-)

А вот интересно, во сколько раз будет разница между 8-битной авр и 32-битным дсп TMS320F2808 на команде, скажем, dmac, которая за один такт перемножает два первых знаковых 16-битных числа, лежащих в памяти, и добавляет это произведение к 32-битному аккмулятору АСС, и в том же такте также делает со вторыми знаковыми 16-битными числами, добавляя результат к 32-битному регистру Р?

Я понимаю, что по-хорошему надо бы написать пгм и посчитать такты, но может у кого-нибудь уже есть двойной МАС для авр?

Ну зайдите в тему, где я выкладывал свой JPEG-кодер для ARM (не для AVR). Там и вышли числа на тестовой картинке ~9 миллионов тактов на AVR и ~4.5 на ARM7.



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



Да, еще можем с суперкомпьютером подходящим сравнить, нам-то что?...

PS Там же blackfin приводил данные для BF. Для такой-же картинки вышло бы ~2.5 миллиона тактов, если мне не изменяет память...

Прямую ссылку можно?

http://electronix.ru/forum/index.php?s=&am...st&p=421275

Ну и можете почитать тему

Еще раз напомню, что для корректного сравнения различных процессоров с помощью JPEG'а нужно сжимать разными процессорами одну и ту же картинку ибо MIPS'ы сильно зависят от того, ЧТО сжимать и КАК сжимать: MIPS summary.

Безусловно. Посему, данные для AVR и ARM7 соответствуют, для BF - ориентировочные (я Ваши 5MI для цветной картинки 320*240 4:2:0 разделил пополам. Чисто для ориентира).

Вы. Я писал про одинаковую (почти) цену AVR и DSP и разницу в количестве операций в 2000 раз, плюс шина 32/8, т.е. 8000 раз при сложениях и где-то 64000 при умножениях, плюс встроенные возвожности вычисления БПФ, плюс конвейер, т.е. отсутсвие дополнительных пересылок. Так что на данной задаче DSP разрывает AVR на сто тысяч маленьких медвежат (с) ненапрягаясь.

зы: нет, я понимаю, строить VGA или там ETHERNET контроллеры на AVR - куда ни шло. Но AVR для ЦОС - зачем же так себя не любить.

Не передергивайте. Вы начали про "восьмибитные мипсы".



Однако, упоминаемая 45я серия Сименсов имеет на борту C166 с тактовой 13МГц. Пусть это будет 26 "восьмибитных мипсов". И имеет голосовой набор. Почему-бы не учесть сей факт? Да и как бы смотрелся тот-же BF в выключателе света?

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

Ну так вы предложение до конца дочитайте. Восьмибитные там значило, что на 16-битных операндах скорость будет меньше на порядок, а на 32-битных - на два порядка. Это чтобы человек 20 мипсами не обольщался.


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

Для подавляющего большинства операций (сложение, сдвиг, сравнение, копирование) - ровно в два раза. Для умножения чуть больше в 3-5 раз. Для некоторых операций скорость даже выросла (напр мастабирование - деление на 2^8 будет быстрее т.к. не нужно делать &).

Так откуда взялась разница на порядок?


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

Распишите на AVR умножение двух 16-битных операндов. Двух 32-битных операндов. (Можно подсмотреть, например у GCC)


Вместо выключателя по компу ? Однако...

32-х битные расписывать не буду, нет смысла. Вначале надо разобраться с 16x.
Решение тупо в лоб:



С ограничениями - произведение не может быть больше 65535.
итого 12 тактов против 2. (в 6 раз, однако не на порядок).
Таблично можно сделать быстрее.


Вы предлагаете вместо каждого выключателя по DSP. А я предлагаю 1 комп вместо всех выключателей.

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


Ну или один матерый ДСП. Идея - зачот

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

Ну так сколько чернил для шестнадцатого класса выдавливается из AVR ?


А думать пробовали ? )


Я комп даже на лампочку в туалет не поставлю. Ну мало ли прижмет срочно, а будешь полчаса упрашивать свой выключатель, как дурак, свет включить )



По отмашке идет _только_ обработка словаря. Это можно и на PC сделать. Да хоть на крейе каком-нибудь. А вот разбор команд - в реалтайм, как ни крути, без отмашек, в шуме и с прочими прелестями.

но не на порядок же больше чем для восьмого. log2 != log10.


А что, смущает размер таблицы? да многовато.. ;> ну можно умножитель на CPLD прикрутить
дорого, но тем не менее потенциальная возможность ускорить с 12 до 6-ти тактов (4xOUT / 2xIN ) или 8-ми тактов (2xOUT, 2xLD) есть.


Главное винду не ставить ;>

Если с такими ограничениями, то последние две инструкции не нужны
Так что минус три такта, остаётся 9.

А вообще, добавлять ro к CH это ошибка. Добавлять надо к третьему байту, которого в вашем случае нет.

Да да!
Спасибо что заметили. Итого 9 тактов!

Не знаю, как по-вашему, для меня один порядок - десять раз. Сэм-восэм или там 12-20 - тоже подходят, я не зануда.


Бред ?



Не вдаваясь: тогда округление логично добавить ?

Куда?

Нет, народ. Это все измерение пиписек. При таком подходе, конечно, AVR не хватит. Надо подходить к решению (к оптимизации решения) задачи в комплексе. Если бы я банально собрал jpeglib, то на AVR оно еле-еле бы шевелилось.

Ну простой пример из моего кодера - в DCT, хоть оно и целочисленное, но удалось уменьшить разрядность умножения (точнее, количество операций mul) в связи с тем, что все коэффициенты, кроме одного не превышают 1, а тот, который превышает, тот так обрабатывается - b=a+(k-1)*a. А там этих умножений - как деревьев, которые все в гробах, - тьма...

И много других хитрых моментов есть.

Вообщем, пока тут всё голословные утверждения, хватит AVR или не хватит. И будут они голословными, пока нет хотя-бы наброска алгоритма.

так ежкин кот, сказал же, отличие по скорости между 8x операндами и 16x операндами в 2 раза.
До порядка далеко.


Такой же как и ставить DSP в выключатель.


Вроде mse говорил что щелкал FFT на m48 в real-time. Вот только сейчас не вспомню где искать. ;>

Ну мы, например, в аудио-тахометре (который измеряет частоту вращения по звуку) тоже не особо извращаемся, тоже FFT на m16. Раз в секудну обновляем показания. Клиенты вполне довольны

Весь вопрос, какого размера FFT нужен. И еще, не следует забывать, что FFT не самоцель. Например, в JPEG-кодере на обычных камнях DCT занимает примерно 50% и примерно 50% занимает квантизация и хаффман. А на BF - 25% DCT (конечно, многоствольные MAC-операции, все дела), остальное - 75%... Вот такая вот загогулина получается.

Еще раз повторюсь, алгоритм надо рассматривать в комплексе.

Ок предлагаю рассмотреть (даже не рассмотреть, а оценить потянет ли AVR) такой упрощенный алгоритм:

1. Зарание расчитать спектры гласных и согласных звуков (их будет упрощенно около 25) и хранить их во флеш.
2. Непрерывно оцифровывать входной сигнал с Fd = 3.2kHz (для 32xFFT на 10ms выборку, 100 выборок в секунду).
3. Для каждой выборки считать FFT в real-time и сравнивать с 25-ю эталонными спектрами.
4. При смене звука запоминать индекс предыдущего.
5. При отсутсвии совпадений с базовыми звуками - преобразовать все запомненные идексы в буквы и как рез-тат получить слово.


Кратко:
Непрерывная оцифровка 1 канала АЦП 3.2kHz
100 FFT на 32 точки за секунду.
2500 сравнений 32х байтных строк в секунду.

1. Ну видимо "заранее" - это вообще "зарание", так что живет отдельной жизнью и основной работе не мешает.

2. Не вопрос. А Fd=3.2 - так задумано?

3a (FFT) - вроде нормально, нет проблем. И вроде-бы недолго. Точно я могу сказать завтра. Кстати, обязательно ли FFT? Возможно ли DCT (ну дабы без комплексной части)?

3b (сравнения) - видимо, по методу наименьших квадратов? Или как? Уточните, плиз...

4 и 5 - ну это вроде тупая логика на 20-30 строк и ненамного больше тактов...

Между вторым и третьим байтом. Ну ежели мы первый и второй решили вдруг отбросить. Или я не понял.



Какжежтак ? 12/2 = 6. А не 2. И что, простите, дальше 10/6 или 6/2 ?



Женщин в расчет не берем ? ) Я за 8kHz на входе(после DAC).


М.б. нужно, чтобы фонема полностью помещалась в буфере FFT ?



Это хотя бы понятно как. Наверно, подойдет для начала.

Вместо евклидовой нормы можно попробовать применить чебышевскую, стоит оценить, т.к. разница может достигать 40%.



Первый и второй остаётся, третий и четвёртый - нули, можно отбросить.

Да так задумано. Если AVR справится с этой задачей, можно будет пробовать повышать Fd.


Думаю возможно, но это будет FCT.


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


Тут согласен.


9/2 = 4.5! это только умножение!
про большинство остальных операций уже упоминалась разница - ровно в 2 раза.
на некоторых операциях таких как "деление на определеннй коэффициент" можно выиграть в скорости.


пока нет - не берем. пока мы хотим проверить что AVR в стостоянии распознать одного мужика