Эхоподавление В WebRTC – Классический AEC + ИИ-гибрид

Кратко

Эхо в браузерном звонке возникает, когда динамик одного собеседника проигрывает голос другого, микрофон ловит этот звук и отправляет копию обратно, – и в WebRTC уже встроен бесплатный модуль подавления эха, AEC3, который снимает большую часть проблемы. Эта статья – о том, где именно этот модуль физически расположен внутри WebRTC-звонка, почему единственный нужный ему сигнал – это звук дальнего конца до любого подмешивания, и как один неправильный «провод» превращает чистый звук в петлю обратной связи. Мы разберём пять стадий AEC3, единственный переключатель в браузере, который его включает, что меняется на iPhone и Android, где работу делает собственное «железо» телефона, и когда стоит выйти за пределы встроенного подавления ради нейросетевого – от Krisp, NVIDIA или открытой модели. Главный повторяющийся урок: в WebRTC проблемы с эхом – это почти всегда проблемы проводки и тайминга, а не «модель недостаточно хороша».

Почему это важно

Если ваш продукт ведёт живой двусторонний разговор в браузере – видеоконференция, телемедицина, виртуальный класс, голосовой ИИ-агент, – эхо это дефект, который пользователь замечает в первые десять секунд и винит в нём вас. WebRTC, технология, позволяющая браузерам напрямую обмениваться аудио и видео, уже включает в себя качественный модуль подавления эха бесплатно, поэтому большинству команд не нужно строить свой. Ловушка в том, что «оно встроенное» скрывает три способа всё испортить: подать модулю неправильный сигнал, поставить второй модуль поверх первого и решить, что браузерное решение одинаково работает на телефоне. Эта статья для продакт-менеджера, основателя или техлида, которому нужно выпускать чистые звонки и объяснять инженерам, почему в звонке эхо. К концу вы поймёте, как WebRTC подавляет эхо, какими переключателями это управляется, почему мобильные устройства – отдельная история, и в какой именно момент платный или открытый ИИ-модуль оправдывает своё место. Теорию того, как устроен любой модуль подавления эха, – адаптивные фильтры, double-talk, ИИ-гибрид – смотрите в статье про основы эхоподавления; эта статья – о том, как заставить его работать внутри реального WebRTC-звонка.

Сначала – что такое эхо в WebRTC-звонке

Прежде чем устанавливать модуль, определим проблему, которую он решает. Звук, поступающий из динамика в микрофон во время двустороннего разговора, называют акустическим эхом. Когда голос удалённого собеседника воспроизводится через динамик вашего ноутбука, он распространяется по комнате и попадает в микрофон вместе с вашим голосом. Без обработки эта записанная копия передаётся обратно, и собеседник слышит свой собственный голос с задержкой в доли секунды – что делает нормальный разговор практически невозможным.

Два слова будут встречаться на протяжении всей статьи, поэтому определим их сразу. Сигнал «дальнего конца» (far-end) – это аудиосигнал от другого собеседника, который ваше устройство собирается воспроизвести через динамик. Сигнал «ближнего конца» (near-end) – это то, что записывает ваш микрофон: ваш голос плюс, к сожалению, эхо звука дальнего конца, разносимое по комнате. Задача эхоподавления – убрать это эхо из микрофонного сигнала ближнего конца, не затрагивая ваш настоящий голос.

Есть второй вид эха, о котором стоит упомянуть, чтобы потом его отложить. Линейное, или сетевое, эхо возникает внутри телефонной сети на электрическом тракте и регулируется старым телеком-стандартом ITU-T G.168. Этот стандарт не охватывает акустическое эхо – то, что отражается от стен комнаты и динамика, – а именно с ним работает любой браузерный звонок. В WebRTC вас интересует акустическое эхо, и профильный стандарт качества терминала – ITU-T P.340 для устройств с громкой связью. Держите эти два вида раздельно: сетевое – чужая проблема; комнатное – ваша.

Единственный сигнал, который делает подавление возможным

Вот самая важная идея во всей теме – и та, к которой сводится большинство багов с эхом. Чтобы устранить эхо, модулю нужна чистая копия звука с дальнего конца – именно тот сигнал, что пошёл в динамик, – как отдельный вход. Эта копия называется опорным сигналом (reference), а в коде WebRTC – сигналом «render». Представьте, что это шумоподавляющие наушники, которым разрешено слышать ту самую музыку, которую они пытаются заглушить: именно знание оригинала делает вычитание возможным.

Модуль работает, предсказывая эхо на основе опорного сигнала и вычитая его. Он строит модель того, как ваша комната изменяет звук с дальней стороны – задержку, отражения от стен, ослабление – и по этой модели предсказывает, как будет выглядеть эхо в микрофоне. Затем он вычитает это предсказание из сигнала микрофона. То, что остаётся, – это только ваш голос.

Поэтому одна ошибка в проводке фатальна. Опорным сигналом должен быть звук дальнего конца – до того, как к нему добавляется что-либо ещё: до вашего микрофона, до любой музыки или звукового эффекта, воспроизводимого приложением. Если очищенный выход случайно подаётся обратно как опорный сигнал, модуль начинает «гоняться за собственным хвостом», и звук рассыпается. На практике, когда в WebRTC-звонке упорное эхо, причина гораздо чаще кроется в сломанном опорном «проводе», чем в слабом алгоритме.

Нажмите, чтобы увеличить

Где живёт модуль: Audio Processing Module в WebRTC

WebRTC не рассматривает подавление эха как отдельную функцию. Оно реализовано внутри модуля обработки аудио, известного как Audio Processing Module, или APM. APM – это компонент WebRTC, который преобразует необработанный аудиосигнал с микрофона в пригодный для передачи в звонке. Он выполняет три задачи в строго определённом порядке: сначала подавляет эхо, затем устраняет шум и, наконец, применяет автоматическую регулировку усиления, выравнивая уровень громкости.

Порядок задан намеренно, и его стоит понять. Подавление эха идёт первым, потому что ему нужен микрофонный сигнал в максимально исходном виде – чтобы выровнять его относительно опорного. Если бы шумоподавление работало раньше и изменяло звук, модель комнаты модуля боролась бы с «движущейся мишенью». Поэтому подавление эха обрабатывает самый «сырой» звук, убирает эхо, а уже потом шумоподавитель устраняет шипение, и регулятор усиления выравнивает уровень. Именно поэтому важно следовать правилу из нашей статьи про шумоподавление в WebRTC: всё, что вы вставляете в аудиотракт, должно соблюдать этот порядок – иначе вы будете конфликтовать со встроенной цепочкой обработки.

Поскольку подавление эха – первая и самая чувствительная стадия APM, она сильнее всего зависит от источника звука и от того, с чем он взаимодействует. Браузер передаёт APM сигнал с микрофона и опорный сигнал воспроизведения, а APM возвращает очищенный звук для кодека Opus – Opus является стандартным голосовым кодеком WebRTC. Спецификация IETF, управляющая аудио в WebRTC (RFC 7874), рекомендует использовать акустическое подавление эха, поскольку браузер не может предполагать, что пользователь использует наушники. Именно эта рекомендация и объясняет, почему модуль включён по умолчанию – к этому мы вернёмся чуть позже.

AEC3: модуль внутри каждого браузера

Конкретный модуль подавления эха, который сегодня поставляется в WebRTC, называется AEC3 – «3» означает, что это третья версия, заменившая более старый десктопный модуль и отдельный упрощённый мобильный AECM примерно в 2017–2018 годах. Он работает в Chrome, Edge и любом приложении, построенном на базе библиотеки WebRTC, то есть прошёл тестирование на огромном количестве реальных звонков. Вы почти никогда не пишете AEC3 самостоятельно – вы просто включаете его и обеспечиваете корректными данными.

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

Вторая стадия – линейный адаптивный фильтр, который выполняет основную работу. «Адаптивный» означает, что он постоянно подстраивает модель помещения по мере её изменений; «линейный» – что он обрабатывает предсказуемую часть эха. AEC3 запускает этот фильтр в частотной области небольшими блоками – по шестьдесят четыре аудиосэмпла за раз, примерно четыре миллисекунды каждый. Такой подход позволяет быстрее вычислять и быстрее реагировать, чем при обработке по одному сэмплу. Хороший линейный фильтр подавляет эхо на уровне от двадцати до сорока децибел – величина, измеряемая метрикой, которую мы определим чуть ниже.

Третья стадия – детектор double-talk, защищающий от самого сложного случая в эхоподавлении: когда оба собеседника говорят одновременно. Когда говорит только дальний участник, фильтр может безопасно обучаться по сигналу с микрофона. Но если вы говорите в этот момент, ваш голос «загрязняет» данные, на основе которых фильтр пытается обучаться, и если он подстроится под ваш голос – система выйдет из строя. AEC3 отслеживает double-talk и приостанавливает обучение фильтра на это время, возобновляя его, как только вы замолкаете.

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

Пятая стадия – комфортный шум – заполняет короткие паузы, создаваемые агрессивным подавлением, мягким синтетическим шипением, чтобы звонок не воспринимался как постоянно прерывающийся.

Нажмите, чтобы увеличить

Число, которое вы реально будете использовать: ERLE

Инженеры измеряют эффективность подавления эха с помощью показателя ERLE – Echo Return Loss Enhancement. Проще говоря, это величина, показывающая, во сколько раз стало тише эхо после обработки по сравнению с исходным уровнем, выраженная в децибелах. Децибелы позволяют сжимать большие отношения в компактные числа, поэтому простая арифметика делает их легко интерпретируемыми.

Допустим, эхо, поступающее в микрофон, имеет определённую мощность, а после обработки AEC3 остаточное эхо составляет одну десятитысячную от этой мощности. Отношение – 10 000 к 1. ERLE преобразует это отношение в децибелы по стандартной формуле:

ERLE = 10 × log10(мощность эха до ÷ мощность эха после)
ERLE = 10 × log10(10 000)
ERLE = 10 × 4 = 40 дБ

Итак, модуль, убирающий эхо в отношении 10 000 к 1, набирает 40 дБ ERLE – верх диапазона, до которого дотягивает хороший линейный фильтр. Практическая ценность этого числа – в отладке. Если вы логируете ERLE у AEC3 и он держится ниже 10 дБ, фильтр не сходится – обычно потому, что оценка задержки неверна или сломан опорный провод. Здоровый звонок показывает, как ERLE забирается к двадцати-тридцати за секунду-две после старта звонка. Когда кто-то говорит «ИИ просто недостаточно хорош», показание ERLE часто вскрывает, что настоящая проблема – в тайминге, а не в интеллекте.

Переключатели в браузере, которыми вы управляете

Для веб-приложения почти всё это управляется одной строкой кода. Когда вы запрашиваете у браузера доступ к микрофону через getUserMedia – стандартный веб-метод, предоставляющий странице доступ к микрофону, – вы передаёте ограничение с именем echoCancellation. Спецификация W3C Media Capture and Streams определяет его, и по умолчанию оно установлено в значение true в Chrome, Firefox и Safari. Если оставить его включённым, вы получаете AEC3 (или собственный модуль системы) без дополнительных усилий.

// Запрашиваем микрофон с включённым подавлением эха (это значение по умолчанию).
const stream = await navigator.mediaDevices.getUserMedia({
  audio: { echoCancellation: true, noiseSuppression: true }
});

Есть второй, менее известный переключатель, определяющий, какой модуль будет использоваться. Chrome добавил ограничение echoCancellationType, которое можно установить в browser или system. «Browser» означает AEC3 – программный модуль, встроенный в Chrome. «System» означает передачу задачи модулю операционной системы, например, Voice Capture DSP в Windows, который физически расположен ближе к аудиоаппаратуре. По умолчанию Chrome использует системный или аппаратный модуль, если он качественный, и переключается на AEC3 в остальных случаях, поэтому вручную это настраивают редко. Такая настройка важна в основном при отладке устройств, у которых аппаратный модуль работает нестабильно, и нужно принудительно перейти на предсказуемый программный путь.

Единственный «переключатель», который нужно соблюдать, а не включать, – это согласованность. Если вы активируете echoCancellation в браузере и одновременно запускаете второй собственный модуль в аудиотракте, вы дважды обрабатываете звук и, как правило, ухудшаете его – та же ловушка наложения, что и губит шумоподавление. Правило: один модуль в цепочке, выбранный осознанно. Мы вернёмся к этому, когда будем обсуждать добавление ИИ-модуля.

Мобильные – отдельная история: работу выполняет телефон

Факт, удивляющий многие команды: на телефоне модуль подавления эха, который вы реально используете, – как правило, не AEC3, а собственное «железо» устройства. И Apple, и Google интегрируют акустическое эхоподавление в операционную систему, настроенное под динамик и микрофон именно этого телефона. Обычно аппаратный модуль превосходит универсальный программный, потому что он адаптирован под конкретное «железо» и лучше его понимает.

На iPhone и iPad ключевой элемент – системный аудиокомпонент, который Apple называет Voice-Processing I/O unit. Когда приложение устанавливает аудиосессию в режим «голосового чата» (voice chat), iOS активирует этот компонент, выполняющий подавление эха, шумоподавление и регулировку усиления, настроенные под конкретное устройство. Однако цена – ограничение: этот режим рассчитан на сценарий, близкий к телефонному звонку, поэтому приложениям, которым нужна нестандартная маршрутизация звука – например, наложение музыки на голос, – может не повезти: системный модуль будет мешать, и придётся выбирать между оптимизированным аппаратным путём и полным контролем над обработкой.

На Android ситуация похожа, но ещё запутаннее. Система предоставляет класс AcousticEchoCanceler, включающий встроенный модуль производителя устройства, – однако качество этого модуля сильно различается среди тысяч моделей Android, находящихся в употреблении. Некоторые флагманские устройства подавляют эхо отлично, а некоторые бюджетные телефоны с трудом справляются с задачей. Из-за этой нестабильности многие серьёзные голосовые приложения на Android игнорируют аппаратный модуль и запускают AEC3 программно, жертвуя небольшим увеличением расхода батареи ради одинакового поведения на всех устройствах. Ключевой фактор – задержка звука: флагман может воспроизвести и перехватить звук за десять миллисекунд, а дешёвый телефон – за более чем сто, и оценщику задержки AEC3 приходится компенсировать этот разброс.

Когда стоит выйти за рамки встроенного модуля

AEC3 и аппаратный модуль телефона справляются с подавляющим большинством звонков, так что разумная позиция по умолчанию – пропустить их и двигаться дальше. Однако существует реальный набор ситуаций, в которых они оставляют слышимое эхо, и у этих случаев общая причина – нелинейные искажения. Классический фильтр исходит из предположения, что эхо – это точное, предсказуемое преобразование опорного сигнала. Дешёвые или громкие динамики нарушают это предположение: они искажают звук настолько, что никакая линейная модель не может его компенсировать – как и при жёстком double-talk, так и в сильно гулких помещениях. Именно в таких условиях нейросетевой модуль оправдывает своё применение.

Нейросетевой, или ИИ, модуль подавления эха заменяет или дополняет классический фильтр небольшой обученной сетью, которая научилась – на тысячах часов реального эхового звука – распознавать и устранять ту «грязную» часть эха, что остаётся после применения традиционных математических методов. Исследовательское сообщество активно продвигало эту идею через ежегодный конкурс ICASSP Acoustic Echo Cancellation Challenge, проходивший в 2021, 2022 и 2023 годах и установивший современные бенчмарки. Одним из заметных результатов стал DeepVQE от Microsoft – единая сеть в реальном времени, способная одновременно подавлять эхо, шум и реверберацию. Сообщалось, что её тестировали для Microsoft Teams – что свидетельствует о переходе нейросетевых модулей из научных статей в реальные продукты. Более новые разработки направлены на создание компактных, эффективных моделей, способных работать на смартфоне без значительного расхода заряда.

На практике такую сеть вы не обучаете самостоятельно – её покупают или используют. Krisp, самый распространённый поставщик голосового ИИ, предлагает подавление эха вместе с шумоподавлением через SDK, который интегрируется в WebRTC-конвейер с помощью WebAssembly и работает непосредственно на устройстве пользователя. Maxine от NVIDIA – переименованная в AI for Media в 2026 году – включает эффект акустического эхоподавления, работающий на видеокартах NVIDIA: есть сборка под Windows для локального использования и под Linux для серверов, как это реализовано в облачном конференц-продукте Tencent Meeting. Полное сравнение этих решений и анализ выбора «разрабатывать или покупать» – в нашей статье про Krisp, Maxine и Dolby; про открытый край спектра – в разборе моделей шумоподавления, где те же семейства моделей всё чаще включают обработку эха.

Куда ИИ-модуль подключается в WebRTC – и почему это неудобно

Решить использовать нейросетевой модуль – лёгкая часть задачи; интегрировать его в WebRTC – гораздо сложнее, и стоит честно объяснить, почему. Браузерный AEC3 глубоко встроен в APM: ваш код не видит звук до того, как он туда попадёт, и вы не можете просто заменить модель в этом модуле через JavaScript. Поэтому собственный модуль должен подключаться только в тех местах, где к нему можно получить доступ – а таких мест всего два.

Первое – на устройстве пользователя, перед собственной обработкой браузера. С помощью AudioWorklet из Web Audio API – стандартного механизма запуска вашего аудиокода вне главного потока – вендорский SDK вроде Krisp сам обрабатывает сырой звук микрофона и опорный сигнал воспроизведения, после чего вы выключаете собственный echoCancellation браузера, чтобы они не складывались. Это путь «на устройстве», и его подвох в том, что теперь вы должны корректно подавать опорный сигнал сами – ту самую дисциплину проводки, которую AEC3 обычно берёт на себя.

Второе место – на сервере. В групповом звонке звук проходит через медиасервер под названием SFU, который пересылает поток каждого участника всем остальным – тот же серверный слой, где размещены более широкие API интеграции WebRTC и ИИ. Нейросетевой модуль, работающий там – сборка Maxine под Linux или управляемая модель платформы вроде LiveKit, – очищает звук централизованно. Это естественно, когда участники звонят с телефонных линий или устройств, которые вы не контролируете и на которых не можете запустить код. Компромисс – стоимость и задержка: серверная очистка работает на вашем оборудовании, за которое вы платите, и добавляет «прыжок», и то, и другое должно укладываться в бюджет задержки до 100 миллисекунд, необходимый для живого разговора. Какое бы место вы ни выбрали, железное правило остаётся неизменным: в цепочке должен быть ровно один модуль. Остальные – выключайте.

Частая ошибка: два модуля конфликтуют

Самый частый самонанесённый баг с эхом в WebRTC – не недостаточное, а чрезмерное подавление: два модуля работают с одним и тем же звуком. Это происходит автоматически, потому что каждый слой по умолчанию «включён». Браузер включает AEC3. Телефон активирует свой аппаратный модуль. Разработчик добавляет Krisp «на всякий случай». Теперь три системы одновременно пытаются смоделировать и вычесть эхо, и поскольку каждая изменяет звук, который видит следующая, они начинают мешать друг другу.

Симптом типичен и легко может быть неправильно истолкован. Вместо чистого двустороннего звука связь становится полудуплексной – работает как рация: ваш голос обрывается каждый раз, когда говорит собеседник. Причина в том, что наложенные подавители шума действуют слишком агрессивно и принимают вашу речь за эхо, подлежащее удалению. Команды часто пытаются «починить» это, добавляя ещё один слой обработки, что только усугубляет проблему.

Лечение – упрощение: отключите все модули, оставив только один. Если используете сторонний SDK, установите браузерный echoCancellation в режим false. Если доверяете аппаратному модулю телефона – не запускайте дополнительно AEC3. Один осознанно выбранный модуль работает эффективнее, чем три, конфликтующих по умолчанию.

Нажмите, чтобы увеличить

Варианты бок о бок

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

Читайте таблицу в соответствии с вашими ограничениями. Если вы используете браузер и обычные звонки – первая строка даёт ответ, и на этом всё. Если вы на iOS, система уже работает правильно. Если вы на Android и качество звука нестабильное, программный AEC3 обеспечивает согласованность. Только когда классическое подавление эха оставляет его слышимым – из-за громких или дешёвых динамиков, интенсивного двойного разговора или гулких помещений – нейросетевой модуль оправдывает свою лицензию и подключение.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Мы создаём живые видеопродукты, зависящие от качественного двустороннего звука – платформы видеоконференций, телемедицинские консультации, где врач должен чётко слышать каждое слово, онлайн-обучение и голосовые ИИ-агенты. Эхо – одна из первых проблем, с которой мы сталкиваемся на любом из этих решений. Наш подход, за который выступает эта статья, строится по порядку: начать с бесплатного браузерного AEC3, проверить его реальную эффективность не по одному тестовому звонку, а с помощью точных измерений, и рассматривать упрямое эхо как следствие проблем с проводкой или таймингом, прежде чем переходить к другой модели. На мобильных устройствах мы действуем в зависимости от платформы – доверяем настроенному «железу» iOS и выбираем между аппаратным модулем Android и программным AEC3 в зависимости от целевой аудитории продукта. Переход к нейросетевому модулю мы делаем только тогда, когда нелинейное эхо не поддаётся классическому подавлению, и при этом сохраняем единый модуль в цепочке обработки, чтобы второй «добросовестный» слой не превратил чистый звонок в рацию.

Ключевые выводы

• WebRTC поставляет бесплатный качественный модуль эхоподавления AEC3, включённый по умолчанию через echoCancellation.
• Единственный обязательный вход модуля – опорный сигнал дальнего конца, до любого смешивания.
• Большинство проблем с эхом в WebRTC связаны с проводкой и таймингом, а не с недостатками алгоритма: сначала проверяйте ERLE и задержку.
• На телефонах обычно работает собственный аппаратный модуль устройства; качество на Android может сильно различаться.
• Обращайтесь к нейромодулям (Krisp, Maxine, открытые модели) только для подавления нелинейного эха, которое стандартный фильтр пропускает.
• Никогда не используйте два модуля одновременно – это вызывает полудуплексный эффект «рации». Запускайте ровно один.

Что почитать дальше

• Эхоподавление – классический AEC + ИИ-гибрид
• Шумоподавление в WebRTC – интеграция RNNoise, DeepFilterNet и Krisp
• Krisp, NVIDIA Maxine и Dolby – покупать или строить движок улучшения речи