Подавление эха на громкой связи, Bluetooth и AirPods

Кратко

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

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

Если вы строите инструмент видеоконференций, платформу телемедицины, онлайн-класс или контакт-центр, ваши пользователи будут вести себя непредсказуемо. Они подключатся с телефона на столе, с AirPods в поезде, с конференц-громкой связи, где сидят шестеро, и с Bluetooth-колонки на кухне с плиточным полом. Каждый из этих случаев – отдельная задача про эхо, и тот же подавитель, что звучит безупречно в вашей гарнитуре, может резать слова или пропускать эхо на их устройстве. Эта статья для менеджера продукта, основателя или операционного руководителя, которому нужно понять, почему одно устройство даёт эхо, а другое нет, чтобы читать тикет поддержки, задать инженеру правильный вопрос и выставить клиенту честные ожидания. Опытный инженер тоже найдёт каждое утверждение со ссылкой на источник – Bluetooth, ITU-T, Apple или Android. К концу вы будете точно знать, почему Bluetooth – самый трудный случай в звуке реального времени и что с этим делать.

Начнём с главного: что нужно подавлению эха, чтобы сработать

Прежде чем перейти к трудным устройствам, держите в голове одну мысль, потому что всё остальное следует из неё. Подавление эха, по-английски AEC (acoustic echo cancellation), убирает звук вашего собственного динамика после того, как он просочился обратно в ваш микрофон. Для этого ему нужна та единственная вещь, которую устройство уже знает: звук, который оно собирается воспроизвести, – опорный сигнал (reference). Подавитель предсказывает, как этот опорный сигнал вернётся в виде эха, и вычитает предсказание из микрофона. Если предсказание хорошее, остаётся только ваш голос. Полный механизм – адаптивный фильтр, детектор двойного разговора, подавитель остатка – разобран в статье Акустическое эхоподавление (AEC): как это на самом деле работает. Здесь нам нужна лишь одна его часть.

Эта часть – выравнивание задержки. Подавитель не может вычесть эхо, пока не знает, насколько позже эхо приходит относительно момента воспроизведения опорного сигнала. Представьте две копии одной песни, одна играет с долей секунды задержки относительно другой; чтобы погасить одну другой, сначала надо сдвинуть их до совпадения. Промежуток, который подавитель должен измерить, – это круговой путь от «звук передан в динамик» до «эхо захвачено микрофоном». В него входят буфер воспроизведения, цифро-аналоговый преобразователь, путь по воздуху через комнату, аналого-цифровой преобразователь и буфер захвата.

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

Лёгкий край шкалы: проводные гарнитуры

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

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

Почему Bluetooth – самый трудный случай в звуке реального времени

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

Переключение профиля: почему наушники ухудшаются в момент, когда вы заговорили

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

Первый – Advanced Audio Distribution Profile, сокращённо A2DP. Это высококачественный стерео-путь в одну сторону. Именно он играет музыку в ваши наушники. Звучит хорошо: стерео, полная полоса, настоящий кодек вроде AAC или aptX. Но обратного канала у него нет. Микрофона в A2DP нет вовсе, потому что музыке он не нужен.

Второй – Hands-Free Profile, сокращённо HFP. Это двусторонний путь, построенный для телефонных звонков. Он несёт звук к динамику и голос обратно от микрофона. Но у классического Bluetooth нет полосы, чтобы вести полноценный стереопоток и микрофонный аплинк одновременно. Поэтому HFP схлопывает звук до одного узкополосного моноканала голоса в обе стороны.

Вот следствие, которое удивляет почти всех. В тот миг, когда ваше приложение открывает микрофон – в миг начала звонка, – наушники должны покинуть A2DP и переключиться на HFP. Стерео-путь музыкального уровня исчезает, и обе стороны падают до моно-качества голоса. Поэтому ваши дорогие беспроводные наушники звучат богато, пока вы слушаете подкаст, и вдруг звучат как мобильник 1990-х в момент, когда вы отвечаете на звонок. Ничего не сломалось. Переключился профиль.

Насколько падает качество? Голос HFP идёт по синхронному каналу с фиксированным бюджетом 64 тысячи бит в секунду. Обязательный кодек, называемый CVSD, дискретизирует на 8 кГц, что захватывает лишь нижние ~4 кГц слышимого диапазона – телефонное качество. Более новый необязательный кодек, mSBC, появившийся в HFP версии 1.6, дискретизирует на 16 кГц (около 8 кГц полосы) и продаётся как «HD Voice» или широкополосная речь. Сравните с AAC из A2DP на 44,1 или 48 кГц в стерео – и обрыв слышен.

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

Движущаяся мишень: почему подавитель не может захватить цель

Переключение профиля – это проблема качества. Задержка – это проблема эха, и она хуже.

Bluetooth-канал добавляет большую круговую задержку, потому что звук пакетизируется, буферизуется, передаётся по радио и снова буферизуется на другом конце. Один только протокол HFP даёт порядка 40 миллисекунд, а полный круг «воспроизведение → захват» на Bluetooth-связке обычно попадает куда-то в ту самую полосу 20–200 миллисекунд – у её высокого, болезненного края. Хуже размера – изменчивость. Радиоусловия меняются, буферы подстраиваются, канал перезаключается, и задержка плавает в ходе звонка.

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

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

Ловушка двойной обработки

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

Решение – не «добавить ещё подавления». Наоборот: на мобильных пусть один подавитель владеет задачей – обычно платформенный или аппаратный – и не ставьте второй программный подавитель поверх уже очищенного сигнала. Знание этого превращает необъяснимый тикет «голос звучит как под водой на одной этой гарнитуре» в однострочный ответ.

AirPods: другая проблема в том же костюме

AirPods постоянно винят в эхе, и обычно они в нём невиновны. Пройдитесь по физике – и станет видно почему.

AirPod сидит запечатанным в ушном канале или у него. Динамик стреляет в ваше ухо, а не в комнату. Поэтому путь от динамика AirPod обратно к микрофону AirPod крошечный – акустического эха почти нет. По оси эха запечатанные наушники ведут себя как проводная гарнитура: проблемы по большей части нет.

Что есть – это всё из раздела про Bluetooth выше. AirPods – это Bluetooth-устройства, поэтому в момент, когда вы принимаете звонок, они переключаются с богатого музыкального пути A2DP на монопуть голоса HFP, и качество вашего голоса падает. AirPods также добавляют реальную обработку на устройстве, чтобы это компенсировать: чип H2 в недавних моделях Pro и AirPods 4 ведёт микрофоны с формированием луча и вычислительный звук, чтобы чистить ваш голос, а функция Apple Voice Isolation использует машинное обучение, чтобы убирать фоновый шум из звонков – доступна в FaceTime с iOS 15, в обычных телефонных звонках с iOS 16.4 и расширена на недавние AirPods с тяжёлыми вычислениями на чипе H2. Так что когда звонок на AirPods звучит плохо, причина почти всегда – деградация кодека из-за переключения профиля или артефакт переключения, а не эхо.

Исключение стоит назвать, потому что оно застаёт команды врасплох. Рассуждение «эха нет» зависит от того, что AirPod в ухе. В миг, когда пользователь вынимает наушники и кладёт их на стол, оставаясь на звонке, динамик теперь стреляет в открытый воздух, микрофон больше не запечатан, и вы снова в полноценной задаче эха открытой комнаты – поверх Bluetooth-канала со всеми его бедами задержки. То же железо, совершенно другая акустическая ситуация.

«Подвох, сказанный прямо. Когда тикет говорит «эхо на AirPods», эхо редко даётся самими AirPods. Проверьте три вещи по порядку: маршрутизировался ли звук через HFP и деградировал (звучит глухо, а не с эхом)? Вынул ли пользователь их из ушей посреди звонка? Не ставит ли ваше приложение программный подавитель поверх голосовой обработки Apple? Настоящее акустическое эхо от запечатанных, вставленных в ухо AirPods – наименее вероятная причина.»

Громкая связь: открытая комната выкручивает каждую слабость на максимум

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

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

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

Третья проблема – двойной разговор, ситуация, когда оба говорят одновременно, и именно на неё будут жаловаться ваши пользователи. Когда подавитель не уверен, что в микрофоне – эхо или голос ближнего, он может зажаться для безопасности и срезать ближний голос. Слышимый результат – полудуплексное поведение: устройство ведёт себя как рация, где побеждает тот, кто громче, а другого обрезают. Международный стандарт для hands-free-терминалов, Рекомендация ITU-T P.340, формально классифицирует такие устройства ровно по этому свойству – полный дуплекс, где обе стороны остаются открытыми, против полудуплекса, где одна сторона подавляется. Дешёвая громкая связь, уходящая в полудуплекс под нагрузкой, не сломана; она делает единственный размен, который ей доступен.

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

Кто владеет подавителем эха на каждой платформе

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

В вебе нужный рычаг – ограничение echoCancellation в API браузера getUserMedia, определённое спецификацией W3C Media Capture and Streams. Его установка просит браузер убрать перекрёстную помеху между устройством вывода и устройством ввода. В десктопном браузере это обычно запускает собственный AEC3 WebRTC в программном виде. На телефоне браузер часто удовлетворяет тот же запрос, маршрутизируя через аппаратный подавитель платформы.

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

На платформах Apple системный подавитель живёт в аудиоюните Voice-Processing I/O, который добавляет подавление эха, подавление шума и регулировку усиления, построенные для голосовых звонков. Вы включаете его, выставив аудиосессию в голосовой режим, например .voiceChat. На iOS и macOS это тот подавитель, что берёт на себя железо и маршрутизацию, включая путь Bluetooth, и обычно он лучше, чем биться с этим путём самому.

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

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

Горизонт: Bluetooth LE Audio и LC3

Проблема переключения профиля – ограничение классического Bluetooth, и у неё есть реальное решение на подходе. Bluetooth LE Audio, появившийся с Bluetooth Core Specification 5.2, заменяет старую дилемму «A2DP или HFP» новой архитектурой на безроялти-кодеке LC3 (Low Complexity Communication Codec). LC3 несёт высококачественный звук на менее чем половине битрейта старого музыкального кодека, а связанные изохронные потоки (connected isochronous streams) LE Audio могут вести высококачественный звук в обе стороны одновременно. Проще говоря: будущий звонок по LE Audio сохраняет хорошее качество и микрофон одновременно – обрыв исчезает.

Честный статус на 2026 год – «приходит, но не пришёл». LE Audio и его широковещательная функция Auracast уже поставляются в новых телефонах, наушниках и слуховых аппаратах, а спецификация Bluetooth Core достигла версии 6.3 в мае 2026 года, но это пока не тот стандарт, на котором говорит каждое устройство на звонке. На ближайшие несколько лет придётся исходить из того, что заметная доля ваших пользователей – на классическом Bluetooth, живёт с переключением профиля и переменной задержкой. Проектируйте на пол, а не на потолок.

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

Мы встраиваем звук реального времени в видеоконференции, телемедицину, онлайн-обучение и live-shopping-продукты с 2005 года, и устройство, с которого пользователь реально подключается, – место, где рождается большинство тикетов про звук. В телемедицине врач на клинической громкой связи с пациентом на AirPods – ровно та комбинация (длинный путь открытой комнаты с одной стороны, переключение профиля Bluetooth с другой), что побеждает наивную настройку, и сделать её пригодной для использования – разница между завершённой консультацией и раздражённым обратным звонком. Большая часть нашей работы здесь – выбор правильного владельца подавителя на каждой платформе, разумная настройка WebRTC Audio Processing Module по классам устройств и осознанное тестирование в условиях Bluetooth, громкой связи и двойного разговора, а не только на той гарнитуре, что носит разработчик. Мы не переписываем AEC3; мы делаем так, чтобы правильный подавитель побеждал на тех неудобных устройствах, которыми реально владеют ваши пользователи.

Главное

• Подавление эха живёт и умирает выравниванием задержки; Bluetooth делает её большой и плавающей.
• Открытие микрофона роняет классический Bluetooth с музыки A2DP до моно-голоса HFP.
• AirPods почти не дают эха – запечатаны в ухе; их проблема – качество HFP, а не эхо.
• Громкая связь совмещает длинный реверб-путь, искажение динамика и двойной разговор разом.
• Выберите одного владельца подавителя на платформу; не ставьте программный AEC на очищенный сигнал.
• Bluetooth LE Audio с LC3 кончает переключение профиля, но классический Bluetooth жив весь 2026.

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

• Акустическое эхоподавление (AEC): как это на самом деле работает
• WebRTC-конвейер звука целиком
• Диагностика проблем со звуком в продакшене: runbook