На правом рисунке сколько по времени ширина выделенной зоны - 5мс ?

По характеру характеристики видно, что до уровня -30дб будет лежать в пределах 9мс -> следовательно желателен алгоритм на 16 мс . (а ниже уровня -30дб включается нелинейный процесс с ограничением амплитуды - clip и додавливает эхо)

Шум автомобиля громкий для эхоподавителя это гуд, он всё эхо и без эхоподавителя задавит )

OSLEC не давит шумы автомобиля . Это из области реализаций AEC.

OSLEC для вашей ситуации более чем достаточно, причём нужно стремиться к уменьшению алгоритма от 16мс до 9мс, найдя оптимум при этом. При меньшем количестве TAP резко улучшается скорость сходимости и качество поиска коэффициентов фильтра.

Если не весь хвост эха будет накрываться фильтром, то эти ненакрытые остатки вы и услышите в остатках эхо или их сьест нелинейный процесс OSLEC. В любом случае чем дальше хвост эха, тем он меньше по амлитуде - тут необходим подбор количеества TAP, чтобы опредилить что нужно давить.

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

Думаю даже, что все мои обьяснения лишние - самое правильное см. первоисточник OSLEC - echo.c

Эхо хоть и короткое, но и неслабое.
ОSLEC или любая другой готовый линейный эхоподавитель подойдёт.
NLMS c dоuble-talk детектором и прочими стандартными наворотами вполне достаточно.
(Но из SPEEX mdf.c был бы ещё круче)
Наверное, лучше всё таки взять готовый. 3 строками не обойдётся. Скорее сотней.

16 мс - это 128 отсчётов, двигайтесь по направлению к 8*9=72 как сказано выше. Не забывайте, что условия стабильности позволяют при этом пропорционально увеличивать шаг адаптации для более быстрой сходимости. Условия стабильности есть везде, можете взять хоть здесь (кратко и на русском)

http://multicore.ru/fileadmin/user_upload/...ectric-echo.pdf
В программе хорошо бы иметь вычисление ERLE для объективного контроля качества.

Вот - половина (большая) дела сделана.
Теперь вы знаете длительность ИХ и соотвественно все понятно по длине фильтра.

Но картинки ваши настораживают вот по таким пунктам

- что это за ассиметричный сигнал в 8000 (*2^-15) амплитуды? к нему два вопроса: 1. самый главный - почему он ассиметричный если это внешний звук или шум 2. он слишком большой
- ИХ имеет слишком большую амплитуду - т.е. все сказанное из динамика с амп 1 попадает в микрофон и после оцифровки получается размахом во всю шкалу. Это очень интересно - и очень плохо

что надо поделать
- посмотрите не стоит ли у вас АРУ где то в канале в том или ином виде - с АРУ надо осторожно, если вообще надо в вашем случае
- порегулировать коэфф усиленя микрофона - он слишком чувствительный у вас прямо сейчас
- разобраться откуда ассимитрия "шумового/внешнего" сигнала

При таком уровне соотношения амплитуд (2^-15*) 8000..6000/32000 = 0.25 вы больше ~-12-15дБ подавления не получите.

Еще интересно - ИХ более менее симметричная в +и-, а вот это "нечто" сугубо в одну сторону - там явно где то косяк.


UPD - вот первая картинка не плохо выглядит в качестве как бы "тишины", а выбросы положительные это что от не то.

Ой ой ой! Нагнал я вчера по ночи
Пропустил я в аудиоредакторе диалог с выбором Intel PCM(LSB,MSB) и Motorola PCM(MSB,LSB) и тупо даванул Ok вчера.
Так вот выдавал я в порт я LSB,MSB а файл открывался как MSB,LSB. От того и такая амплитуда импульса вышла.
Waveform промасштабирован в недетское кол-во раз чтобы хоть что-то было видно(справа есть шкала - по ней можно сориентироваться по сравнению с предыдущими скриншотами).
И взял другую трубку - там на фоне вообще почти полная тишина получается.

На самом деле выглядит это так:

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

И как следствие можно вообще ничего не делать в этом направлении.

Проверьте все еще раз на всякий случай. Один из вариантов - проговариваете в динамик речь и пишете что слышит микрофон. Если вы ИХ правильно намеряли записанная речь должна быть в теже дБ что на картинке меньше.

Влепил я туда OSLEC.
Попариться пришлось не очень много.
Стандартный Сишный код по быстродействию реалтайма мне не обеспечил, поэтому пришлось закатать рукава и поработать над асмовой оптимизацией фильтра. На этом пути меня ждало много интересного. Раньше оптимайзил плывучие функции Speex, поэтому о переполнениях, Sign extension и прочем даже не задумывался. Я тут вот, пришлось узнать об этом по подробнее

Только что произвел тестовый звонок. Длина фильтра = 80 отсчётов.
Небольшие отдельные кусочки эха иногда прослушиваются, но достаточно тихо и совсем ненавязчиво.
Дабл ток проверю завтра ибо собеседника мне не найти - все спят уже

Разберусь до конца с оптимизацией, посмотрю, поиграюсь с длиной фильтра... думаю всё будет замечательно!

ВСЕМ СПАСИБО ЗА ПОМОЩЬ!

посмотрите сюда
http://focus-webapps.ti.com/general/docs/s...opic=1653260327
там и про акустическое и электрическое эхо есть теория ипрактика.

Там есть несколько классических Application Notes, а в основном жлобские 3-d party реализации, за много килобаксов, соизмеримого качества или даже хуже. Фирменные коммерческие реализации вовсе не лучше Open-source по части алгоритмов. Главная особенность гнушных open-source реализаций - это межплатформенная мобильность. Поэтому гнушные алгоритмы реализуются на С, а вся оптимизация там крайне сомнительна. Лишь бы дырки заткнуть. Open-source реализации таким образом нацелены в будущее (производительность будет расти вместе с производительностью процессоров без всяких программистских затрат), а коммерческие реализации нацелены на текущие сиюминутные прибыли - примерно раза в три производительней, но умрут вместе с конкретным процессором или платформой :-)

В open-source нам доступны реализации всех основных алгоритмов -
mdf - в SPEEX
nlms - в OSLEC
fast RLS - в LEC/AEC



Если выч. ресурс достаточен, не стремитесь минимизировать длину фильтра - оставьте с запасом, например 128 .
Совсем небольшие похрюкивания <-40 дб часто порождаются нелинейными эффектами и линейными алгоритмами не подавляются.
В стандарте предлагают для их подавления использовать нелинейные ограничители опционально. Т.е. оставить возможность выбора между незначительной потерей качества передачи слабых сигналов и незначительным остаточным нелинейным эхом.

Поиграйтесь с длиной фильтра в частности и параметрами алгоритма вообще. Всё будет кокаколой ))

Всё кокаколой! Спасибо! Там в ослике надо было ещё заюзать такие штуки как ECHO_CAN_USE_TX_HPF и ECHO_CAN_USE_RX_HPF.
Реально выручили меня именно эти фичи, которые я изначально не включил и таки вместо похрюкиваних <-40 дб получал вполне приличные отрывки эха, когда громкость динамика/чувствительность микрофона ставил побольше.
Сейчас используются все фичи эходава, включая нелинейный ограничитель ECHO_CAN_USE_NLP.
Хоть бы что-то хрюкнуло! Тишина теперь вообще! )))))))))))

Конечно OSLEC это супер, когда он вышел все просто обалдели. Просто есть ряд задач, типа подавление в потоках E1 - где софтом много не выжать, зато for. ex вариант от зарлинк ZL38070 на 256 каналов, в принципе ничего, да стоит вроде недорого - 200EU

чё-то ослик всё куда-то убегает

После 5 - 7 мин работы он почему-то решает, что адаптироваться до полной тишины на много выгоднее(так точно эха не будет).

Кароче тишина. Я конечно сделаю сброс через каждые 60-80сек, но что-то как-то непорядок однако.

Ещё потом точно проверю бит экзактность с визуал Си кодом на длиииинных массивах входных данных...но на коротеньких(500-600отсчётов) - всё как положено.

5-7минут не пробовал - проверю на своём алгоритме. То есть в трубку тишина, из трубки речь ... Через 7 минут речи уже и не слышно... Это странно : тк если на входе эхо-модели ноль, то и воссоздаваемый отклик тоже ноль и соответственно из речи ничего не вычитается. Думаю проблемы где-то в области программирования.

даа-так и есть

Скорее всего где-то маху дал, когда оптимизировал...

Add: проблема была в области программирования, но не в коде OSLEC. Оказалось я в главном цикле с поинтерами накосячил, а OSLEC падал жертвой buffer overflow