Я в этих делах не так силён....может быть ссылку хотя-бы на блок-схемку...
ну уж если на готовый open source проект - так это вообще чудо из чудес.
По ссылкам, которые Вы давали - один line echo canceller, а второй наглухо коммерческий

Там во-втором есть исходники, используйте в порядке ознакомления ))
Цитата

MIKET DSP Solutions provides FREE SOURCE CODE for the following high-quality eXpress DSP (xDAIS © TI) compliant algorithms for building next-generation telephony and tele/video-conferencing plaftorms, designed for 'C55xx/C54xx DSP archiectures:

G.167 Acoustic Echo Canceller is capable of providing perceptually full duplex quality in above-average sized office rooms when used even in inexpensive speakerphones with a single omni-directional microphone.
AEC supports echo tails up to 400ms and, in addition, provides up to 15 dB of noise reduction (Ephraim-Melah).

Line Echo Canceller in optimized to provide the maximum attainable, fully transparent voice quality for de-echoing of a PSTN or POTS connection in VoIP / LAN systems with internal delays, or on a codec end of a telecom switch (20ms echo tail).
Call for a long tail version.


Free Source, понятно... Не OpenSource, сообществу ASTFIN автор добро не дал пока на распространение с GPL лицензией
Там очень хороший, очень современный алгоритм

Какой у Вас хоть процессор? Скрываете всё, ничего не понятно, всё нужно угадывать, Вас нужно пытать - zltigo здесь прав
На LEC - то хоть хватит ресурсов? Основа любого эхоподавителя - адаптивный фильтр и при минимальной длине на 20 мс ему требуется
по минимуму примерно 2 млн операций в сек при хорошей ассемблерной оптимизации. На С больше, зависит от процессора, может в 3 раза

Вообще-то, если Вы не имели дела с адаптивной фильтрацией, портирование к себе может оказаться слишклм трудоёмким.
Может всё-таки SPEEX? И уменьшать длину линии задержки, чтобы спасти ресурсы.

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

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


Может и speex.....очень может

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

В лоб скорее не получится. Эхо-отклик зависит от положения руки, уха и, потом, будет стареть, в зависмости от состояния микрофона

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

По первой моей ссылке, OSLEC, кстати проще чем в SPEEX, и всем хорош для Ваших целей, ссылка на статью там ниже тоже есть. Он принят за стандарт в сообществе ASTERISК, разработчиков OpenSource PBX. Проблема только в том, что алгоритм уже интегрирован в драйвер для Линуксов и может оказаться довольно
сложным его оттуда выковырять даже несмотря на исходники

Спасибо. Если всё так - то и правда speex допилить будет проще т.к. уже есть опыт общения(сношения) с ним.
FFT библиотека техасовская есть, ещё пара функций на асме и ресурсов проца хватит...сложнее с оперативкой...но там посмотрим...

oslec вообще-то растет из spandsp, и выковыривается на раз. также можно глянуть на mg2 canceler из mISDN - прост как валенок. там в комплекте идут еще несколько canceler'ов, но качество их не очень.

Аффтар топика
- какая платформа в виде софта? если ли оболчка в виде ОС?
- есть ли прямой доступ к цифре аудио-потока "из" микрофона и "для" динамика? внимательно подумайте над этим вопросом.

далее, если окажется что все хорошо с аудиоканалом - вам повезло
- решение у вас будет пару тройку функций по 20-50 строчек кода
- читаем гугл на слова LMS адаптивный фильтр, потом читаем NLMS
- потом читаем про DTD

все применительно к AEC - акустичскому ехо подавлению

- получить свои 15-20дБ подавления вы получите - если остальная часть системы как то кусок от микрофона до цифры сделан нормально.

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

Ну и в конце немного про начало - сначала узнайте скажем АЧХ вашего эхо-канала - это сразу покажет насколько у вас все хорошо или плохо.


А так же интересно в чем прикол разработки? чисто что любобытно, да и полегче будет помогать.

>- какая платформа в виде софта? если ли оболчка в виде ОС?
Софт полностью самописный на Си. Вокодер speex с asm оптимизацией кое-где.... никакой ОС нет.
>- есть ли прямой доступ к цифре аудио-потока "из" микрофона и "для" динамика? внимательно подумайте над этим вопросом.
Используется сигма-дельта АЦП/ЦАП TI AIC12K. Собираем отсчёты с микрофона в буфер(т.е. вот она цифра). Такой-же буфер выходных отсчётов отправляется на ЦАП(т.е. опять имеем доступ к цифре). Или что имелось тут ввиду?

>если остальная часть системы как то кусок от микрофона до цифры сделан нормально
Критерий нормальности? Может и не нормально....

Цель разработки: шифрование переговоров. Как это называется....скрамблер что-ли

Итак у вас техас 28хх серии для всего с голосом (микрофонить и говорить)
и телефон в качестве модема с передачей данных по CSD, при это вам нравится непрозрачный режим.
понятно.
а какой именно телефон? - ну это уже чисто любопытсво.

немного в сторону -а чем не нравится вот такое решение?
http://www.signal-com.ru/ru/prod/phones/phones_345/index.php
чисто софт пописать?

но тем не менее - к делу

первое и самое главное вам надо узнать АЧХ акустического эхоканала вашего телефона (назовем это так). Особенно полезно знать длину Импульсной Характеристики. как только станет ясна длина - все станет сразу понятно по ресурсам. как только станет ясно с линейностью - сразу станет ясно насколько хорошо будет работать адаптивный фильтр с алгоритмом адаптации NLMS - что есть простое и эффективное решение во многих (простых ) случаях.

получите цифры и картинки - покажите
а там и готово уже почти.

>Итак у вас техас 28хх серии для всего с голосом (микрофонить и говорить)
К нему аудиокодек(АЦП/ЦАП). Ну а в общем-то - да и микрофонить и говорить )))

>получите цифры и картинки - покажите
Хорошо.

Непрозрачный режим ооочень ненравится, но куда деваться-то!

В системе используется оригинальный алгоритм шифрования и аппаратный генератор случайных чисел.
Софтовые реализации хакаются.

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


есть стандарты на шифрование, а вот "оригинальные алгоритмы" - они как раз и хакаются .
ну это к вопросу дела не имеет.

Точно, oslec понимается легко и написан так, что не содержит делений!

mg2 не смотрел - Цитата про mg2 ) :
"
Thanks for OSLEC, it's so much better than my hacked KB1 which is called MG2 :-)
"
Author of the Zaptel MG2 echo canceller
— Michael Gernoth

Спасибо, посмотрим.
Щас пока жду платы, чтоб всё собрать уже и протестит в реале, так сказать.
Вопросец я задал с опережением, так сказать, чтоб помощь пришла раньше проблемы
Но проблема будет - это я уже чую.....

Простите, сэр, вас случайно не Григорием величать? (у вас личный ящик письма не принимает)

Итак, к делу

Почитал пару-тройку статеек с сайта OSLEC. Вроде всё красиво... буду пробовать.

По снятии АЧХ вроде вопросов особо нет, воспроизводим синус частотой скажем от 50 до 4000Hz и смотрим что получается на входе с микрофона.
А что воспроизвести, чтобы определить длину импульсной характеристики? Подать на ЦАП что-то вроде [MIN,MAX,MIN].. Но я сомневаюсь, что он вообще что-то воспроизведет, не говоря уже о том, чтобы микрофон что-то поймал...