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

Кратко

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

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

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

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

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

Что есть – это всё из раздела про Bluetooth выше. AirPods – это Bluetooth-устройства, поэтому в момент, когда вы принимаете звонок, они переключаются с богатого музыкального профиля A2DP на голосовой профиль HFP, и качество передачи вашего голоса падает. AirPods также используют дополнительную обработку на устройстве, чтобы компенсировать это: чип H2 в последних моделях AirPods 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