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

В девайсе использован вокодер Speex, однако стандартная реализация его echo сanceller очень громоздка и предназначена больше для организации громкой связи. Для применения этой фичи as is нет оперативки, да и оптимизировать опять много чего придётся.....в общем не вариант.


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

Как бы сделать простое "вычитание" воспроизводимого динамиком сигнала из того, что поступает в микрофон и не передавать удалённому абоненту его-же голос?

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

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


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

Подавление ближнего эха (которое на дальнем конце звучит с задержкой) - это функция АТС, а не трубки.
Даже если у Вас будет трубка такая большая, что в неё можно засунуть хороший трасформатор или dsp-процессор с линейным эхоподавителем или вообще отключите свою трубку, ближнее эхо (отражённый сигнал) будет возникать для удалённого абонента на Вашей АТС при проигрывании сигнала в аналоговую линию примерно 50 ом+- 100% волнового сопротивления ))

С какого бодуна, удаленный конец должен бороться с эхом ставшим заметным по причине неприеслимо больших задержек создаваемых ВАШМИ кодеком. На дальнем конце, если обеспечили удовлетворительный уровень отражения и не внесли существенных задержек, то и не обязаны ни за что "бороться".

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

Ближнее, на то оно и ближнее, что сколь-нибудь существенной задержки НЕТ ВООБЩЕ.

Аналоговый двухпроводный Абонентский Комплект составляет собой неразрывное целое с Телефоном и рассматривать их по отдельности просто невозможно.

Дальше вообще помолчу.

Где Вы такое прочитали у меня? Напротив, я написал, что всякая станция должна подавлять своё "ближнее эхо", которое на противоположном конце становится дальним. Про "Вашми кодек" - это Вы придумали

Ну и дальше в том же духе. Борьба с собственными фантомными фантазиями

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




Рекомендации, тогда еще, МКТТ всосаны, можно сказать, с молком матери. И осенью 25 лет, как занимаюсь связным оборудованием. Посему то, что Вы где-то слышали, читали в интернете, .... можете оставить при себе.


А я прочитал и сообщаю, что написанное Вами есть каша из разрозненных явлений, фактов и слухов.

Я и не писал статью. Здесь, например, можно найти более систематическое изложение


http://www.commsdesign.com/showArticle.jht...icleID=16502325

Можно догадаться, что канал - всё таки цифровой (раз там где-то кодер SPEEX), тогда "трубка" эмулирует станцию ( не телефон!), следовательно автору нужен линейный эхоподавитель (раз не спикерфон)

Совсем простых методов компенсации не получится (акустический эхоподавитель в любом случае сложнее линейного. но и линейный вычислительно тоже не прост) В SPEEX эхоподавитель, насколько я помню, реализован в float и на базе FFT. В этом смысле, алгоритм может быть проще - если реализовать в fixed-point (возможно быстрее) и NLMS (возможно меньше памяти). А в остальном, алггоритм в любом случае не может быть простым. Ближнее эхо только по сравнению с дальним "без задержки", а на самом деле имеет протяжённость во времени и "тупо вычитать" не получится.
Нужен ближний эхоподавитель, обычно делают на протяженность 16 мс(128 тапов) импульсной характеристики отклика, может можно попробовать меньше (4 мс ?), если связь чисто аккустическая (прямое подключение АЦП и ЦАП без гибрида и линии) и линейная

В open source есть эхоподавители на С, NLMS здесь, хоть тормоз, конечно, но хоть, кажется, не float
http://www.rowetel.com/ucasterisk/oslec.html
Здесь даётся ещё более лучший эхоподавитель LEC в исходниках C. Он RLS, в исходниках,есть акккустический, есть вариант для tms5х, но, строго говоря, не совсем open source ))
http://www.miketdspsolutions.com/
Можно попробовать извлечь оттуда содержательный код и сократить линию задержки до минимума...

Аппаратные AEC+LEC рассматриваются?

Ошибку свою понял. Термин телефон я использовал в вопросе необдуманно.

Это радует. На это вся надежда
У обоих.
Такой-же как я. Система коммутации "голос в пакетах". Используется непрозрачный CSD.

Проблема в следующем(как я её вижу): Абонент 1 говорит привет, голос оцифровывается, жмётся вокодером и передаётся по цифровому линку.Далее, по этому линку наше привет идёт 800ms(где-то так и идёт). Т.е. абонент 1 уже давно закончил выговаривать привет и ждёт.
Тут Абонент 2 наконец слышит Привет из динамика своего телефона(прошло 800ms). При воспроизведении слова Привет, на стороне Абонента2 этот-же привет воспринимается микрофоном Абонента 2 как речь, оцифровывается, жмётся и отправляется на сторону Абонента 1. Проходит ещё 800ms и Абонент 1 слышит свой Привет, но, естественно уже тише....
Как я понял, это какраз far echo. Т.е. фильтрацией должен заниматься Абонент 2. И делать он должен это по принципу: я не воспринимаю на входе микрофона ту аудиоинформацию, которую сам-же воспроизвожу через свой динамик.

нет. Некуда там даже резистор лишний припаять

P.S. Спасибо за ссылки, щас гляну. float'ом нас не напугать. Проц с FPU брался специально с учётом того, что исполнитель(я) неопытный и плывучка пригодиться. Вообще, speex собран float. По причине наличия FPU - такой подход оказался быстрее по тестам.

Ну да, это far эхо для абонента 1
для абонента 2 (да и по происхождению) это near эхо и именно он должен его подавлять
Теоретически всегда эхо должно подавляться ближним концом, но можно при звонке в село попасть...
В Сев. Америке подавляют и континентальное "среднее эхо" 40-60мс по принципу мало ли через какие шлюзы Вы подключились.
Т.е. при звонке в село в Южной Америке эхо подавят, если оно даже в селе или по дороге не подавлено. Но при звонке из Канады в Подмосковье на старую станцию... неподавленое местное эхо прёт по полной.
Вообще источников эхо много - каждый шлюз, где происходит переход с 4-х проводной линии (или цифровой, что то же самое) на 2-х проводную комутируемую линию абонента или аналоговый 2-х проводный транк между станциями. Как то так. На каждом переходе возникают отражения.

Far эхо, на 800 мс и более обычно не подавляют - это сложно и дороо

Трубка есть терминал и ничего она не эмулирует. Что такое Вы назвали "линейным" не совсем понятно, ибо в терминологии по отношению к терминалу эхо "Acoustic" и "Network".
Что имел ввиду Автор - еще более непонятно - пока не начнет на наводящие воросы отвечать - сполшное гадание.

Если под линейным подразумевается "Network Echo Canceler", то в самом общем случае со стороны сети может быть все, что угодно в том числе и дополнительно Акустическое Эхо удаленной стороны . В частном случае, действительнго проще.

А вот "Ближний" уж точно не нужен - у Автора без вариантов цифра, значит "четырехпроводка" и на ближнем конце нет эха по определению. Наиболее вероятно речь идет об эхе дальнего конца с уровнем порядка -20-30dB, возникающим при переходе на аналоговую двухпроводку ТфОП, незаметным при задержках до, примерно, 4ms, но в данном конкретном случае бьющем по ушам из-за очень большой задержки вносимой SPEEX кодеком в "Трубке". Компенсация этого безобразия целиком и полносттью лежит на породившией эту выходящюю за рамки допустимой зажержку "Трубке" и никак не на стороне Сети. Хотя стороны Автор чего-то вещал про невозможность удовлетворительно развязать "трубку", посему вероятны и проблемы из-за акустической связи+большой задержки на удаленном конце, даже при полной "четырехпроводке".



Нет, это чистой воды акустическое эхо со всеми его прелестями. И давить его должен тот, кто порождает - трубка, которая не обеспечивает физическое подавление. Это правильно, ибо свалив эту проблему с больной головы на здоровую (удаленный конец), Вы только добавите проблем ввиде необходимости еще и ДОПОЛНИЕЛЬНО компенсироваить многосот мииллисекундные, причем нестабильные, задержки канала.

Автор объяснил уже, что он проигрывает сигнал от удалённого абонента 1 через свой динамик, из-за чего и имеет аккустическое "ближнее" эхо
на своём микрофоне. Для абонента 1 - это дальнее эхо, что его раздражает )) Короче, он должен давить его как ближнее эхо на своём конце, очевидно. Ближнее в смысле задержки, а не терминала. В смысле 'короткий"

Линейный эхоподавитель - это линейный эхоподавитель. Такой как я дал по ссылке )) У телефонистов может и network, особенно если поставят на станции готовый многоканальный ))
В IP-телефонии, те кто его делал, говорят, обычно, линейный.
Я делал, потому говорю - линейный. Потому до сих пор дальнее эхо прёт, когда звонишь из Канады в Подмосковье ;-)) Шютка
Типа того http://blog.astfin.org/

Ну и каша у Вас в голове, опосля чтения "интернету" Причем тут "станции"? Network в обсуждаемом случае не могут поставить на станции просто по той простой причине, что он давит эхо которое пришло из СЕТИ. И стоять он в описываемой системе, может только в терминале aka "Трубка" со стооны СЕТИ. Ну то, что он в данном конкретном случае, после объяснений Автора, не нужен, как класс, я уже писал - для данного случая достаточно одного эхозаградителя в "Трубке" - только с противоположной Сети стороны - Акустического. Поскольку шлюзования в аналоговые двухпроводные сети нет, то и Network заградитель нигде не нужен.

Где он должен стоять и какой, я давно догадался и объяснил своими словами 5 постов назад :-)
Это у Вас каша в голове при чтении меня :-)

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

как минимум адаптивный линейный эхоподавитель/ Так он называется в литературе по ЦОС
Вариант "акустический эхоподавитель" более сложный, Вам же не понравился в SPEEX/
Принцип там тот же - адаптивная фильтрация- но ещё навешено всяких прибабахов.

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

Я в этих делах не так силён....может быть ссылку хотя-бы на блок-схемку...
ну уж если на готовый 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].. Но я сомневаюсь, что он вообще что-то воспроизведет, не говоря уже о том, чтобы микрофон что-то поймал...

только следует учесть что oslec это линейный эходав, здесь все же больше подходит акустический

АФФтАр жжош!!!

Ну как. Мы же определяем характеристики эхо канала.
Т.е. связи динамика с микрофоном. Таким способом мы получим на какой частоте какая амплитуда получается.
А вот касательно импульсной характеристики мне не всё понятно. Внутренний голос(не смеяться) мне подсказывает, что в моём случае длиной импульсной характеристики есть общая задержка от момента, когда на вход DAC подан сигнал до того момента, когда он в том или ином виде появится на выходие ADC и сойдет в 0. Иными словами - реакция на импульс прекратится и система перейдет в исходное состояние.
Как я понимаю это позволит прикинуть tail length для фильтров и от этого, как уже сказал ryhor, надо плясать при определении ресурсов.



Это да. Просто fontp сказал, что он будет всем хорош для меня и пока я ему верю
А что с чем должно быть линейно? Ну т.е. тут мне не совсем понятна суть. Меня тоже насторожили вчера слова
Echo cancellers depend on the hybrid working in a linear mode all the time
Буду очень благодарен тому, кто раскроет мне суть понятия линейности в данном случае.

P.S. Я же говорил - я в этих делах только разбираюсь щас.

хз что тут с форумом - меня самого не пускает к личным сообщениям - хотя там горит что их 2 штуки - написал админам - ответу нету.

ваше мыло в профайле ругается - типа не правильно
отпишитесь ryhor (одна собака) tut.by






что бы измерить длинну Импульной Характеристики (ИХ) надо видимо вспомнить определение ИХ.

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

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



Запостите картинку ИХ - интересно посмотреть
кстати на какой часатоте работает звуковая система? 8кГц?

1. Нет. Ну я хоть и чайник в этих делах, но определение ИХ помню
Мой вопрос какраз и заключается в том, КАКОЙ именно импульс подать в систему? Для цифровой системы там всё ясно: импульс минимальной длительности и максимальной амплитуды. А тут же всё не так просто.

2.Я понимаю, что у меня нет гибрида(в том виде, в котором он присутствует а аналоговых тел. сетях).
Читаю я OSLEC:So we have three signals going to/from the echo canceller:
1. tx: the transmitted speech we are sending down the line сюда подам то, что сейчас воспроизводится в динамике
2. rx: the received signal, which will contain the echoэто у меня будет то, что я "поймал" с микрофона
3. ec: the (hopefully) echo cancelled signalа тут будет rx-tx Т.е. цель постигнута. Из near end сигнала был удалён far end и послан он обратно не будет. Следовательно на том конце человек не услышит своего эха
Для эходава ведь гибрид - это просто штуковина, которая отбивает эхо. Т.е. если мой "эхоканал"(аккустич. связь между динамиком и микрофоном) сможет вписаться по параметрам и выдаваемое эхо будет сравнимо по параметром с гибридом, то тогда этот ослик сможет работать в моей железяке

Главные вопросы, на которые я пока не могу найти ответа:
1. Echo cancellers depend on the hybrid working in a linear mode all the time Что тут имелось ввиду? Может ли мой уже,правильно, аккустический канал хотя-бы теоретически вписаться в это требование? Что тут имеется ввиду под словами working in a linear mode?
Мы не рассматрываем ведь loud speeker вариант, а связь идёт по корпусу девайса....Но пока я толком не понял что тут с чем должно быть линейно - я не могу оценить может ли это что-то быть линейно у меня в девайсе. тут мне нужен комьюнити help, так сказать
2. Какой импульс мне нужно подать и как? Я планирую воспроизведение какого-то импульса в динамик телефона(подача импульса на вход ЦАП) и собираем данные с выхода АЦП. Строим график, смотрим. Правильно ли я мыслю? Какой именно импульс я должен воспроизвести?
3. Ну и по поводу снятия АЧХ канала, после коментария DRUID3 мне аж самому стало интересно а как же действительно нужно было снимать АЧХ моего эхоканала? и действительно ли она необходима?

Система работает на частоте 8 килогерц. Телефония кароче

Никому верить нельзя, даже себе. Мне можно (с)

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

Echo cancellers depend on the hybrid working in a linear mode all the time означает очень простую вещь - что эхо отклик линеен по отношению к передаваемому сигналу. Для телефонного гибрида это обычно не совсем так - нелинейность нагрузки приводит к тому что появляются нелинейные продукты от передаваемого сигнала, которые, естественно не подавляются линейными адаптивными фильтрами. Поэтому в аналоговой телефонии адаптивными фильтрами эхо давится только до уровня 30-40 дб и ухом с чувствительностью 50-60дб прослушивается. В стандарте эхоподавления предлагается добивать нелинейные продукты,например, нелинейными компандерами - супрессорами
Но ваш микрофон и динамик - линейные устройства, особенно в слабосигнальном режиме

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

ну тогда первая строка гугла на запрос "импульсная характеристика"

http://ru.wikipedia.org/wiki/Импульсная_переходная_функция

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

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



я немного повторюся - для акустического канала вам надо
1. найти ИХ - в частности ее длину - отсюда станет ясна длина вашего адаптивного КИХ фильтра.
2. поглядеть АЧХ - насколько оно линейное - т.е вы в него синус - а оно вам в ответ насколько не синус? но тут если уж совсем каких то косяков железячных нет - все должно быть более менее - посему это больше как упражнение на разминку.
3. читаем про LMS и NLMS адаптивные фильтры.
4. Делаем реализацию фильтра с КИХ (3-4 строчки?) и реализацию "адаптатора" этого КИХ фильтра алгоритмом NLMS - столько же строчек по существу вопроса.
5. смотрим на результат - радуемся или плачем - в зависимости от успеха
6. думаем про "детектор двойного разговора"
7. конец
... через какое то время
8. если хочется бооольшего подавления - начинаем читать про RLS алгоритмы адаптации


Никакие готовые проекты вам не помогут - точнее они не нужны ибо сил на их анализ и привязывание к вашей ситуации надо гораздо больше чем сделать самом. Т.е. или вы осознаете что вам надо или нет:
если нет - готовые решения не помогут
если да - они вам не нужны
- вот такие пироги. По сути же вопроса (если не вдаваться в теорию по уши как говорится) - надо реализовать два алгоритма каждый из которых математически выражается одной строчкой. Один это КИХ, второй это NLMS. Но не вдаваясь в теорию "совсем ни капли"- вы не сможете их правильно применить - получается надо таки разобраться .
Можно глубоко, можно "по месту" - вот реализация КИХ с NLMS - это нормальное такое начало для получения более менее годного для практического применения результата без погреения себя в дебрях обработки сигналов.

Обычно в целочисленной реализации 3-4 строчки никак не получается, даже 30-40 не получится. Но к счастью, у автора темы процессор - floating-point.
NLMS можно было бы давно уже сделать в десяток строк. На floating-point процессоре, если время сходимости не напрягает - вообще может работать простейший LMS с очень низким коэффициентом адаптации, причём double-talk-detector в этом случае не нужен. ( Для 16-разрядных вычислений такое никак не пройдёт - потому не используется - у TI есть Application по поводу проблем LMS, порождённых разрядностью)

да ладно 3-4 строчки на КИХ хватит
ну там проверить не нули ли пришли в гости - но это лабуда

NLMS в целых числах - 5 строчек считая вместе с "for(..."
ну там да - пару строчек до и пару после

Т.е. согласен - на все про все КИХ + NLMS 30-40 строчек в самый раз.

UPD - да пересмотрел - действительно что бы быстро и точность не сильно губить в 16 битах приходится немного цикл развернуть (unroll) и пошаманить. Однако у автора плавующие звери.


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

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

Так КИХ не отдельно, КИХ внутри цикла LMS

Я представлял себе это так - достаточно быстрая адаптация при калибровке или вначале сеанса связи. Пока клиент снимает трубку - даблтока нет.
Можно щелкнуть дельта-функцией или даже послать случайный шум в динамик. Главное, чтобы адаптация завершилась пока клиент несёт трубку к уху. А это секунда
Потом работать с очень низким коэф. адаптации. Некорелированый с передатчиком шум и базар при слабой адаптации ничего не собьёт. Аналоговые модемы так и работают - замораживают коэффициент адаптации после стартапа до минимальных значений. Малый кооф.адаптации даёт большое время сходимости,да, но малую ошибку оценки.
Кстати это и есть самый простой способ измерения импульсного отклика - LMS c малым коэффициентом адаптации. Если оценить все проблемы синхронизации при прямом измерении. Но я не думаю, что ему нужен импульсный отклик, разве что из любопытства. Ему нужен LMS! ))

Ну как любят мух отдельно от каклет - смешивать фильтр и адаптивный алгоритм - это на любителя

Адаптация 20дБ за 1 сек - это очень и очень хорошо - это даже вроде по какому то ИТУшному стандарту, но LMS и даже NLMS ее в среднем обеспечить не могут. Обычно надо несколько секунд. Потом пулять самому шум из своего динамика это конечно тема, но часто вы видели шипяще щелкающие телефоны в природе? Обычно пока дальняя сторона наговаривает нам в динамик местный фильтр успевает настроится и обеспечить отсутсвие эха для нее. Далее - акустический эхо канал устанавливается постепенно - например после того как пару динамик-микрофон к голове приложили он может и поменяться и в дальнейшем опять может поменяться - поэтому примораживать адаптацию на совсем немного "опасно".

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





Начнем с конца - какой длинны LMS ему таки нужен? Хватит 32 тапа? или там все 200мс эха?
Ну и как бы ИХ меряется очень просто - посредством измерения ИХ . Кстати не вижу какие там проблеммы с синхронизацие? пикнул и пиши звук.

а вот LMS с малым коэф. может намерять такого что никакой ИХ не снилось. Как долго давать адаптироваться? Ну в общем то в сферическом (в вакууме) случае они конечно сойдутся к одному и тому же, но все же лучше дейстовать прямыми методами, тем более что они проще и гораздо менее подвержены ошибкам.

На любителя разносить их в разные циклы ))



Стандарт G168 требует адаптацию за одну секунду до -30 дб(на широкополосном сигнале, не на синусоиде, на синусовом сигнале эхоподавители адаптируются плохо) и NLMS её ВСЕГДА обеспечивал с запасом лет 20 уже как. 1 сек, это "не очень хорошо", а 'так себе". Теретически сходимость зависит от собственных значений функции автокорреляции сигнала, длины фильтра, коф. адаптации. Для фильтров длиной 16 мс, используемых наиболее часто в качестве "ближних" эхоподавителей, NLMS адаптируется по g168 на ура. Ш-ш-ш! и всё, какие там секунды... Когда эхоподавитель делал я, это Ш-ш-ш! происходило от щелчка подключения кодека к аналоговой линии. Когда говорун начинал говорить, а слухач слушать реально адаптация уже давно заканчивалась :-)

Если длинный фильтр - 200 мс )) - то тогда да, может быть и проблема с NLMS (устойчивость требует снижать коф. адаптации обратно пропорционально длине адаптивного фильтра), но длинные эхоподавители это особая песня.

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

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



Я вижу Вам нечего делать и просто хочется поспорить со мной. Вместо того, чтобы помогать вопрошающему автору топика.
Я не говорил, что без DD - лучше. Я говорил, что всё зависит от уровня эха. При слабом, линейном, медленно меняющемся эхе может оказаться,
что кроме линейного LMS ничего больше и не нужно. Сделать LMS, посмотреть как работает, если нет - то переделать в NLMS. Если нет - приделать дабл-ток-детектор и прочие прибабахи (обычно адаптацию выключают не только на даблтоке (сильном принимаемом сигнале с дальнего конца) и но ещё и при слабом передаваемом сигнале). Адаптивный фильтр работает как коррелятор, накопляя коррелированую с входом компоненту выхода. Если коф. адаптации маленький, то он не выключен, просто он накопляет её очень медленно. ( Выключен при малых значениях коэффициента адаптации он действительно получается при 16-разрядной реализации фильтров. Но это просто потеря точности. При хорошей точности вычислений он работает, но неспешно. Почему Вы так уверены, что параметры среды будут меняться быстрее? Кончайте Вы "активно" заниматься словоблудием )



Опять Вы торгуетесь как на базаре )) Вопросы всегда есть - с одно стороны, с другой стороны...

Проще всего выяснить практически - сделать 128 тапов и уменьшать (или увеличивать). Если там 200 мс эха, то нужен действительно настоящий акустический эхоподавитель или скорее проще похерить вообще всю эту "трубку", ввиду ограниченности ресурсов процессора.
Хватит ли 32 тапа? Вы кого спрашиваете? Я не знаю. Скорее всего нет. Но есть надежда, что 128 хватит. Почему? Отвечаю сразу, чтобы Вы больше ко мне не цеплялись. Я конечно не знаю, что там за трубка. Всяко бывает. Но опыт такой. Когда-то я делал эхоподавитель для порта FXO, к которому аналоговый телефон подключался напрямую. Можно предположить, что эхо в такой ситуации возникает не только от нескомпенсированости импедансов на гибриде (эхо линии), но включает и прямую аккустическую компоненту с телефонной трубки. Так вот, такое "ближнее эхо" отлично компенсировалось адаптивными фильтрами длиной 12 мс (96 отсчётов), независимо от используемых телефонных аппаратов.
Т.е. незначительное аккустическое эхо присутствует всегда на аналоговых аппаратах. Но это не значит, что нужно всегда использовать сложные аккустические эхоподавители, придуманые больше для громкой связи.
Традиционные "ближние" линейные эхоподавители на АТС и тех же мобильниках эффективно давят эту слабую акустическую компоненту.

В сферическом вакуме - это "пикнул и пиши". Назаписываете шума и наводок вместо ИХ да ещё запутаетесь с синхронизацией начала. А LMS с исчезающим коф. адаптации даёт на шумоподобном сигнале то что нужно и теоретически и практически.

умилительно читать ваше словоблудие - нет с вам спорить никак не есть самоцель

чисто пытаюсь уберечь людей от:
- измерения ИХ посредством LMS
- веры что NLMS сходится всегда и быстро независимо от окружения


я покажусь занудой но задача стоит
- сделать Акустический Эхо Подавитель

я спрошу только один вопрос - вы точно делали акустический эхо подавитель (на цифровом или что как бы есть одно и тоже что и без канала связи)? - потому что судя по потоку мыслей вы делали что то другое. Отсюда видимо и советы а-ля измерять ИХ посредством LMS или ненужности DD при (N B)LMS алгоритмах. Так же радует глаз уверенность в невозможности изменения эхоканала в процессе работы - бывает конечно что он и стоит как вкопанный, но чаще нет и именно пока несут к уху он и меняется.

NLMS, LMS никогда не сойдутся ни к -30 и ни к -20дБ если в момент поднятия трубки (что есть начало работы адаптаро) в микрофон будет попадать сторонний (не из эхоканала) звук. Не сойдется он ровно на столько на сколько будет ему мешать этот сторонний источник. Я тут не причем - это природа такая, а теория ее только описывает. Как ни странно практика ее подтверждает.

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

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

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

1. Во всех телефонных модемах без частотного разделения между тем до сих пор используется простейший LMS в эхоподавителях.
Несмотря на встречный сигнал. Последнее время такое начали делать даже в радио-модемах. На непрерывном даблтоке.
Кроме того во всех модемных эквалайзерах для измерения ИХ обычно используется LMS по традиции. И это ничего))

2. В линейных голосовых эхоподавителях до сих пор используется NLMS в большинстве случаев. RLS - хорошо, но используется реже,
поскольку требует значительно больших вычислительных ресурсов. Несколько лет назад RLS вообще не использовался.
Я не спорю - в настоящих голосовых эхоподавителях dauble-talk детектор используется всегда. Но настоящие эхоподавители предназначены для "настоящего" эха.
3. Чтобы сделать всё по уму на все случаи жизни, нужно взять и сделать акустический эхоподавитель. А не морочить голову людям в форумах.
Но здесь обсуждается как бы не делать АКУСТИЧЕСКИЙ эхоподавитель. Я говорил, что для очень слабого и короткого эха это реально.
4. Вы и есть зануда, а не кажетесь. Предположения, конечно приходится делать, за неимением точных данных, но я не собираюсь просить за них у вас прощения.

добавьте к сигналу ближней стороны скажем -20дБ шума и посмотрите куда ваш NLMS сойдется и как быстро он будет это делать.


ало внимание - у нас голос


Шуметь придется в свой динамик что бы свой микрофон поймал сигнал - посему:
- причем тут канал?
- как можно не слышать шум из динамика своего телефона?
- как его услышит микрофон если его не слышит ухо?
- как громко надо шуметь что бы быть эффективным на фоне внешних шумов?

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

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


да я уже план-график расписал чего делать и как.



Что значит я уверен или не уверен? я тут не причем - это все природа. Хочет меняет хочет не меняет . Т.е. как бы дело не в уверенности или не уверенности, а в том что практика говорит (в прямом смысле в этом случае ). Т.е. еще раз параметры эхоканала - меняются (считайте что это дано).

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


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

А G.168 - что? Стандарт для голосовых линейных шумоподавителей. Естественно требования стандарта не могут относиться к голосу. Ало
Всякий голос нестандартен. Естественно, стандарт содержит набор воспроизводимых тестов. Без всякого голоса

Остальной ваш шум, нет смысла обсуждать



Бла-бла-бла
Всё меняется в этом мире. Проблема в балансе - как быстро меняется по отношению к адаптации.

_{я близок к тому что бы засчитать ваш слив хе хе хе}
но как бы аннонсированная цель - помочь автору топика
посему я повторю свой рецепт:


могли бы вы привести кратко возражения по существу (или привести ваш план график работ)? При этом думать не обо мне, а о задаче и ее решении т.е. сделать это так что бы это было полезно автору топика?

Я вроде бы и не возражал против плана Заметил только, что в 3 строчки не получится

Завтра, не смотря на праздник, постараюсь поработать и до вечера выложить ИХ и АЧХ дабы уже более-менее прикинуть что к чему...

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

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

P.S. на fontp не наезжайте, по моим наблюдениям(возможно субъективным) он даёт дельные советы в 99 случаях из 100

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

Замерял импульсную. Возмущения от импульса видны на отрезке 5ms - далее "подстилающий" шум кулеров
АЧХ не мерял. Уровень импульса приличный!

Прилагаю три пикчера(слева на право):
1. без подачи импульса(отладочная плата) - 250ms
2. без подачи импульса(всё смонтировано в телефон) - 250ms
2. подан импульс(всё смонтировано в телефон) - тут видна 71ms область, где наблюдаем импульс

Мне не удалось добиться более-менее чистого графика без подачи импульса. Как-то странно он улавливает шум компа...
Всё 10раз проверил - ошибок никаких не нашел. Думается мне, что может вовсе и не шум это, а наводки от цифровой части....
Замер делал так-же на отладочной плате - там микрофон просто висит в воздухе и никакого корпуса нет. Выдаёт примерно такую-же рваную картину, но только на порядок(а то и на два) меньшей амплитуды.... На слух ничего этого не слышно. Делал loopback, посылая отсчёты ADC сразу в DAC.

Видно, что импульс совпал во времени с всплеском шума/помехи(характерный резкий скачек вверх и окончание с провалом)...
Я постарался выделить область, где мы имеем поданный импульс и реакцию на него.
Получается 5-6ms. Ну и в любом случае не более 11(это если вообще всё выделить).
Но амплитуда, конечно, внушительная получается

Думается мне, что проблема будет успешна решена достаточно коротким фильтром с LMS адаптацией.

Всё-таки пока не до конца понятно как будет работать фильтр, скажем, вот в такой обстановке как у меня.
Шум + пробившийся от динамика сигнал(в данном случае импульс). А шум может быть постоянным и достаточно сильным(к примеру в автомобиле)...

Сам механизм работы непонятен.
Т.е. за желаемый результат мы принимаем тишину(в случае отсутствия дабл тока) и начинаем адаптировать фильтр. Т.е. по идее, если шум меняется медленнее, чем адаптируется фильтр - то всё хорошо будет(заодно и шум тоже сведем на нет). Но тут у меня другой вопрос: а что если шум "длиннее" фильтра? Будет выкусывать из него куски и шум превратится в ....
Чуток подскажите тут, чтоб у меня уже мозайка сложилась, так сказать.

Сложно ли реализовать нормальный дабл ток детектор? Читал, что в OSLEC у них там были кое-какие проблемы с этим делом....