Детектор речевой активности (VAD) и прерывистая передача (DTX)

Кратко

Детектор речевой активности, или VAD, – небольшой модуль голосовой системы, который много раз в секунду определяет, слышит ли микрофон речь или только фоновый шум. Прерывистая передача, или DTX, – это то, как система использует это решение: когда никто не говорит, она перестаёт отправлять полные аудиопакеты и вместо них передаёт крошечный «описатель тишины», сокращая трафик неактивного микрофона примерно на 90 процентов. Чтобы тишина не звучала как обрыв связи, приёмник воспроизводит тихий подобранный шум – так называемый комфортный шум. В этой статье объясняется, как VAD принимает решение, как DTX и комфортный шум превращают его в реальную экономию, а также разбираются два режима сбоев – обрезанные первые слоги и рваная речь, – которые могут возникнуть из-за небрежной настройки и испортить опыт пользователей.

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

Если вы занимаетесь видеоконференциями, телемедициной, контакт-центрами или онлайн-обучением, большинство участников молчат большую часть времени – они слушают, а не говорят. Постоянный поток аудиоданных от каждого молчаливого микрофона расходует трафик и нагрузку на серверы, а в крупных звонках именно это определяет, выдержит ли система 500 человек или рухнет уже на 50. Эта статья предназначена для продакт-менеджера, основателя или операционного руководителя, которому нужно понять суть компромисса достаточно глубоко, чтобы принять решение и задать инженеру точный вопрос – а не изобретать детектор с нуля. Старший инженер найдёт здесь каждое утверждение с ссылкой на исходный RFC, рекомендацию ITU-T или реализацию от мейнтейнера.

Проблема: микрофон, который не умолкает

Начнём с того, что именно передаётся по сети во время звонка. Микрофон непрерывно захватывает звук, кодер разбивает его на небольшие фрагменты – обычно по 20 миллисекунд, такие фрагменты называют фреймами – система упаковывает каждый фрейм в пакет и отправляет. Двадцать миллисекунд на фрейм означают пятьдесят фреймов в секунду, то есть пятьдесят пакетов в секунду, пока звонок активен.

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

Решение состоит из двух частей, которые всегда работают вместе. Первая – это определение: этот фрейм – речь или тишина? За это отвечает детектор речевой активности, который далее будем называть VAD – модуль, прослушивающий каждый фрейм и помечающий его как «речь» или «не речь». Вторая часть – действие: если фрейм – тишина, прекратить отправку полных пакетов. Это и есть прерывистая передача, или DTX – передача, которая может останавливаться и возобновляться, а не идти непрерывно. VAD принимает решение, DTX действует на его основе. Без VAD, который обеспечивает его данными, полезного DTX не бывает – поэтому эти две технологии почти всегда рассматривают как единое целое.

Как детектор речевой активности принимает решение

У VAD одна задача и жёсткое ограничение. Задача – проанализировать текущий фрейм и выдать один бит: речь или нет. Ограничение – сделать это немедленно, почти не опираясь на будущее, потому что живой разговор разрушается, как только круговая задержка превышает примерно 300–400 миллисекунд. Поэтому детектор не может ждать дополнительного звука перед принятием решения.

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

Три поколения VAD используют эту идею всё более изощрёнными способами.

Классический телеком-детектор речи (VAD), стандартизированный в Рекомендации ITU-T G.729 Annex B (1996), был разработан для работы в телефонной сети. Он использует четыре признака – полную полосу энергии, низкочастотную энергию, меру спектральной формы и частоту переходов через ноль – для принятия решения «речь / не речь» и непрерывно отслеживает фоновый шум, чтобы порог автоматически подстраивался по мере изменения уровня шума в помещении (ITU-T G.729 Annex B, 1996). Этот алгоритм стал эталоном, с которым сравнивали более поздние решения.

WebRTC VAD, встроенный в Chrome, Edge и большинство нативных голосовых приложений, – это тот, с которым реально работают инженеры. Он разбивает каждый фрейм на шесть частотных полос, вычисляет энергию в каждой из них и передаёт эти значения в небольшую статистическую модель – смесь гауссиан (Gaussian mixture model). Этот метод хранит один грубый шаблон «энергии речи» и один – «энергии шума» и определяет, на что больше похож текущий фрейм. Модель обрабатывает фреймы длительностью 10, 20 или 30 миллисекунд и имеет единственную настройку – «агрессивность» от 0 до 3: при значении 0 система охотно распознаёт речь, а при 3 – наиболее склонна считать всё шумом. Повышение агрессивности позволяет отфильтровывать больше шума, но повышает риск обрезать тихие участки настоящих слов (WebRTC common_audio/vad, исходники libwebrtc).

Нейросетевой VAD, современный выбор по точности, заменяет ручные правила небольшой сетью, обученной на тысячах часов речи и шума. Широко используемый открытый пример – Silero VAD – компактная модель (около 309 тысяч параметров, примерно 1–2 мегабайта на диске в версии 5, 2024 год), которая обрабатывает звук блоками по 512 отсчётов (32 миллисекунды при частоте дискретизации 16 кГц) и учитывает немного контекста из предыдущего блока, чтобы распознавать ход речи, а не оценивать каждый фрагмент изолированно. На обычном CPU она работает намного быстрее реального времени – разработчики указывают задержку около 1 миллисекунды на блок – и сохраняет высокую точность на множестве языков и в условиях различных шумов, где детекторы по энергии терпят неудачу (заметки к релизу Silero VAD v5, 2024). Платой за это становится необходимость распространять файл модели и незначительное увеличение вычислительной нагрузки по сравнению с шестиполосным подходом.

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

Две ошибки, которые может совершить любой VAD

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

Ложноотрицательная ошибка – это когда настоящую речь система ошибочно распознаёт как тишину. В результате передача прерывается посреди слова, и слушатель слышит, как первый слог фразы «съедается» – «…брый день, коллеги» вместо «Добрый день, коллеги». Это жалоба на обрезанную речь, и пользователи ненавидят её больше всего, потому что потеря слов разрушает понимание.

Ложноположительная ошибка – это когда шум принимают за речь. Система продолжает отправлять полные пакеты во время тишины, так что вы теряете часть экономии, которую должен был обеспечить DTX. Неприятно для облачного счёта, но незаметно для пользователя.

Эти две ошибки напрямую переходят друг в друга, и «ручка агрессивности» – это регулирующий параметр. Сделайте VAD более агрессивным – он будет отсеивать больше шума (меньше ложных срабатываний, больше экономии), но начнёт обрезать тихие окончания слов (больше пропущенных случаев). Сделайте мягче – речь останется целостной, но экономия исчезнет. Настройки, устраняющей обе проблемы сразу, не существует; любая реальная система выбирает точку на этой компромиссной линии. Инженерный приём, позволяющий смягчить проблему обрезания речи, – hangover (хвост удержания): после того как VAD перестаёт детектировать речь, система продолжает передавать ещё несколько фреймов – короткий хвост – на случай, если говорящий просто делает паузу между словами, а не закончил говорить. Классический VAD из G.729 Annex B использует именно такой шумозависимый hangover для защиты конца речевого сигнала (ITU-T G.729 Annex B, 1996). Он требует немного дополнительного трафика для удержания линии, но экономит большую часть тикетов, связанных с обрезанными словами.

Прерывистая передача: действие по решению

Как только VAD определяет, что отрезок – тишина, DTX решает, что именно отправить по каналу. Наивный вариант – ничего не передавать – имеет серьёзную проблему, которую телефонная индустрия изучила ещё десятилетия назад: полная цифровая тишина воспринимается как поломка. Когда тихий фоновый шум комнаты, существовавший мгновение назад, внезапно обрывается и превращается в абсолютное ничто, слушатели полагают, что соединение оборвалось, и начинают спрашивать: «Алло? Вы там?»

Решение – не переходить в полную тишину, а передавать крошечный пакет, который по сути означает: «воспроизводи тихий шум, имитирующий фоновый фон, пока я не скажу иначе». Этот пакет называется описателем вставки тишины, по-английски SID (silence insertion descriptor), а сам шум, который приёмник воспроизводит на основе этого пакета, – комфортный шум, генерируемый генератором комфортного шума (CNG).

Структура этого SID-пакета стандартизована. IETF RFC 3389 (сентябрь 2002) определяет RTP-нагрузку, несущую параметры комфортного шума: один байт уровня шума (насколько громким должен быть шип – в dBov, то есть относительно максимального уровня системы) и необязательные байты, описывающие спектральную форму шума (его «цвет» – басовитый гул или яркий шип) в виде коэффициентов отражения (RFC 3389, §3). Приёмник использует эти параметры для локального синтеза подходящего шипа. Обратите внимание, чего в пакете нет: никакого реального звука. RFC 3389 разработан специально для старых кодеков без встроенной обработки тишины – G.711, G.722, G.726 – и основан на схеме комфортного шума из Приложения II Рекомендации ITU-T G.711 (февраль 2000), которая, в свою очередь, заимствует VAD и DTX из G.729 Annex B (RFC 3389, §2). Нагрузка использует фиксированный тип RTP-нагрузки 13 при тактовой частоте 8 кГц (RFC 3389, §4).

Вот арифметика, которая делает всё это оправданным. Обычный голосовой пакет в звонке WebRTC содержит 20 миллисекунд кодированного звука – для речи в Opus это около 40–80 байт полезной нагрузки, отправляемых 50 раз в секунду. Пакет SID / комфортного шума несёт лишь байт уровня и несколько спектральных байт – всего несколько байт – и передаётся гораздо реже, потому что шум в помещении почти не меняется от момента к моменту.

Активная речь:  20 мс на фрейм → 50 пакетов/сек, ~40–80 байт нагрузки каждый
Тишина (DTX):   описатель ~2–3 байта, шлётся лишь раз в несколько сотен мс
Итог:           нагрузка неактивного микрофона падает примерно на 90%

Разобранный пример. Допустим, один участник во время речи передаёт 60 байт полезной нагрузки Opus каждые 20 мс – это 60 × 50 = 3000 байт в секунду. Тот же микрофон, когда он неактивен и работает в режиме DTX, отправляет один 3-байтовый описатель каждые 400 мс – это 3 × 2,5 = 7,5 байт в секунду. Снижение нагрузки составляет примерно 99,75 % на неактивном потоке – экономия действительно впечатляющая, поскольку большинство микрофонов в звонке большую часть времени находятся в неактивном состоянии. (Когда вы снова учтёте фиксированные заголовки RTP, UDP и IP, полная экономия на одном потоке оказывается меньше, чем экономия полезной нагрузки, но всё равно остаётся значительной – поэтому эмпирическое правило для всего звонка звучит как «десятки процентов», а не «девяносто девять процентов».)

Как работает Opus – и одна ловушка

Opus – кодек, обеспечивающий почти весь аудиопоток в WebRTC, – имеет встроенные VAD, DTX и комфортный шум, поэтому современный стек редко использует отдельную реализацию RFC 3389. Встроенный VAD Opus работает в речевой части кодека (в модуле SILK) и анализирует каждый фрейм по энергии частотных полос и спектральной плоскостности – по тем же признакам, что описаны выше. Когда включён DTX и VAD определяет тишину, Opus кодирует фреймы примерно раз в 400 миллисекунд вместо каждых 20 – а декодер заполняет паузы с помощью встроенного механизма маскировки потерь и комфортного шума (реализация Opus; инженерные заметки getstream.io по WebRTC, 2024).

Три важных факта из спецификации – те, что касаются точной настройки:

Во-первых, DTX выключен по умолчанию. Формат RTP-нагрузки Opus определяет параметр сессии usedtx, и «если значение не указано, по умолчанию 0» – то есть непрерывная передача (RFC 7587, §6.1, июнь 2015). DTX нужно запросить явно.

Во-вторых, когда Opus сбрасывает тихие фреймы, он должен сбрасывать только целые фреймы такого размера, чтобы последовательные временные метки RTP отличались на величину, кратную 120 – тогда приёмник сможет определить, что пробел вызван намеренным DTX, а не потерей пакетов, и использовать целые фреймы для маскировки (RFC 7587, §3.1.3). Приёмник различает DTX и потерю пакетов, анализируя разрыв во временных метках на фоне порядковых номеров (RFC 7587, §3.1.3).

В-третьих – и это ловушка – не сочетайте Opus со старой нагрузкой комфортного шума по RFC 3389. Opus генерирует комфортный шум самостоятельно; накладывать на него RFC 3389 избыточно и явно не рекомендуется стандартом: «Использование Comfort Noise по RFC 3389 с Opus не рекомендуется» (RFC 7587, §3.1.3). RFC 3389 предназначен для кодеков, не обладающих собственной обработкой тишины, а не для Opus.

Вторая ловушка, на которую стоит обратить внимание: DTX в Opus активируется в речевом режиме, а не в чисто музыкальном. Если принудительно перевести кодек в музыкальный режим или настроить его так, чтобы тракт тишины никогда не включался, вы будете платить полную цену за неактивные микрофоны – даже при использовании usedtx=1. Выбирайте режим кодека в соответствии с типом контента: голос для звонков, а не музыку.

Частая ошибка: включение DTX не по назначению

DTX – почти бесплатные деньги для разговоров, где участники говорят по очереди, а большинство микрофонов остаются выключенными. Это неправильный выбор по умолчанию для трансляции непрерывного звука – музыкального выступления, диджей-сета по WebRTC, аудиоинсталляции или радионяни, чья задача – передавать тишину комнаты. В таких случаях «тишина», которую распознаёт VAD, и есть нужный слушателю сигнал, а DTX будет обрезать мягкие пассажи, заменяя их синтетическим шипением. Сам стандарт подтверждает это: при отсутствии жёстких ограничений по сети рекомендуется непрерывная передача, поскольку DTX обеспечивает чуть более низкое качество звука по сравнению с отправкой каждого фрейма (RFC 7587, §3.1.3). Правило простое: DTX включён – для разговоров, выключен – для прослушивания тихого звука.

Есть и взаимодействие настроек, о котором стоит предупредить инженеров. DTX стоит ниже шумоподавления и регулировки усиления в тракте захвата. Если шумоподавитель работает агрессивно, VAD видит более чистый сигнал и лучше определяет наличие тишины; если регулировка усиления «накачивает» почти тихую комнату, VAD может принять усиленный шипение за речь и удерживать поток активным. Эти компоненты не независимы – их настраивают совместно.

У VAD есть вторая карьера: он не только про экономию трафика

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

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

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

Фора Софт с 2005 года внедряет звук в реальном времени в видеоконференции, телемедицину, онлайн-обучение и live-торговлю. В таких системах настройка VAD и DTX – рутинная, но важная задача: телемедицинский звонок требует мягкого VAD с длительным временем удержания (hangover), чтобы тихие реплики врача не обрезались, а вебинар на 500 человек нуждается в агрессивном DTX на каждом микрофоне аудитории, чтобы медиасервер не перегружался неактивными пакетами. Мы подбираем этот баланс под каждый продукт, отслеживаем метрики обрезания речи и частоты пакетов и отключаем DTX там, где контент – непрерывный звук, а не диалог. Тот же сигнал «речь / тишина» затем используется для функций транскрипции и определения «активного спикера», которые пользователи видят на экране.

Главное

• VAD определяет, речь или тишина, на каждом фрейме; DTX использует это решение, полностью останавливая передачу во время тишины.
• Во время тишины система отправляет небольшой описатель вместо полного отсутствия данных, чтобы приёмник мог проиграть подобранный комфортный шум.
• Две основные ошибки VAD: обрезание настоящей речи (пользователи это ненавидят) и пропуск тишины (в этом случае теряется экономия).
• «Hangover» – передача короткого хвоста после окончания речи – устраняет большую часть жалоб на обрезанные слова.
• У Opus DTX включён по умолчанию (usedtx=1), но отключён, сбрасывает целые фреймы и не рекомендует использовать комфортный шум согласно RFC 3389.
• Отключайте DTX для потоков непрерывного звука, например музыки – он может обрезать тихие пассажи, которые важны для пользователей.

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

• Конвейер звука WebRTC целиком
• Opus: открытый кодек, который покорил WebRTC
• Джиттер-буфер: NetEQ, мозг звука WebRTC