Шумоподавление в реальном времени в WebRTC – RNNoise WASM, DeepFilterNet и интеграция Krisp AI

Кратко

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

Путь «собственная модель в клиенте» предполагает запуск таких решений, как RNNoise (лёгкая, бесплатная, скомпилированная в WebAssembly) или DeepFilterNet (более тяжёлая, но качественнее) внутри AudioWorklet – небольшого узла браузерной звуковой системы, работающего вне основного потока. Путь «сервер» означает использование лицензированного управляемого движка, например Krisp AI – on-device SDK, лежащего в основе Discord и RingCentral, а теперь интегрированного с LiveKit, Twilio и Daily.

Главное правило: шумоподавлению требуется сырое, несжатое аудио, поэтому оно должно находиться до Opus-энкодера – и ни в коем случае не внутри WebRTC Encoded Transform, где доступны только уже сжатые кадры.

Эта статья описывает три точки вставки, обвязку для каждой, ловушку двойного подавления, которая ухудшает качество, и помогает выбрать между RNNoise WASM, DeepFilterNet и Krisp AI для реального WebRTC-продукта.

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

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

Статья для продакт-менеджера, основателя или инженерного лида, которому нужно решить, как чистое аудио встроится в WebRTC-продукт, и говорить об этом с инженерами, не попавшись на удочку красивой демо. К концу вы будете понимать аудиотракт WebRTC достаточно, чтобы знать, почему шумоподавление должно стоять до энкодера, как RNNoise и Krisp AI реально подключаются к живому звонку, почему два подавителя одновременно работают хуже и как выбрать между «собрать самому» и «купить управляемый движок».

Если вам нужно глубокое сравнение моделей шумоподавления по скорости, качеству и лицензиям – смотрите нашу спутниковую статью про модели шумоподавления. Эта же статья – про то, как их встроить в WebRTC.

Аудиотракт WebRTC и три дома для подавителя

Чтобы правильно разместить подавитель, сначала нужно представить, как звук проходит в WebRTC-звонке. Путь всегда одинаков: микрофон захватывает звук, браузер немного его обрабатывает, затем аудио сжимается кодеком – почти всегда Opus, который WebRTC требует от каждого браузера (IETF, RFC 7874). Сжатый аудиопоток отправляется по сети, часто через сервер SFU – Selective Forwarding Unit, реле, копирующее поток каждого участника всем остальным. На приёмной стороне аудио распаковывается и воспроизводится в динамике слушателя.

Слово «сжатое» здесь – самое важное, поэтому закрепим его. Сжать аудио – значит убрать часть деталей, чтобы данные стали достаточно компактными для передачи – как сохранить фото в формате JPEG вместо полноразмерного оригинала. После сжатия Opus отдельные звуковые сэмплы теряются; остаётся плотная последовательность байт, которую декодер преобразует обратно в приблизительный звук. Запомните это – от этого зависит всё, что будет дальше.

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

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

Начните с того, что у вас уже есть: встроенный подавитель

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

// Запрашиваем микрофон со встроенными шумоподавлением и эхоподавлением.
navigator.mediaDevices.getUserMedia({
  audio: { noiseSuppression: true, echoCancellation: true },
  video: false
});

Опция noiseSuppression – часть стандарта W3C Media Capture and Streams, спецификации, определяющей, как веб-страница получает доступ к микрофону (W3C, Media Capture and Streams). Когда вы устанавливаете её в true, браузер активирует встроенный подавитель шума. Это бесплатно, не требует интеграции, и аудиоданные не покидают устройство.

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

Почему шумоподавление не может работать в закодированном пространстве

Когда команды решают добавить собственный подавитель, первая ошибка – использовать не тот API. WebRTC предлагает функцию под названием Encoded Transform, которая позволяет запускать свой код на медиа по мере их прохождения через звонок, и на первый взгляд кажется идеальным решением. Однако для очистки аудио это неподходящий инструмент, и осознание этого – ключ к главному правилу.

Стандарт WebRTC Encoded Transform запускает ваш код на закодированных кадрах – на аудио после того, как кодек Opus уже его сжал, между энкодером и модулем, упаковывающим данные для сети (W3C, WebRTC Encoded Transform). Вспомните аналогию с JPEG: к этому моменту отдельные звуковые сэмплы уже утрачены и заменены сжатыми байтами. Подавитель шума работает, анализируя сам звук – какие частоты относятся к голосу, а какие – к шуму, – и приглушает шум. Он не может сделать этого со сжатой упаковкой байт, как нельзя стереть человека с фотографии, редактируя данные сжатого файла. Encoded Transform предназначен для задач, которые оперируют сжатой упаковкой целиком, например для сквозного шифрования. Для шумоподавления это неподходящий уровень.

Верный слой – сырое аудио: несжатый поток звуковых сэмплов до обработки энкодером. Браузер предоставляет два способа доступа к сырым аудиоданным. Первый – традиционный и широко поддерживаемый путь: AudioWorklet из Web Audio API, небольшой узел обработки звука, который браузер запускает в отдельном звуковом потоке (W3C, Web Audio API). Второй – современный подход: MediaStreamTrackProcessor, который выдаёт каждый фрагмент микрофонного аудио в виде сырого объекта AudioData, доступного для чтения и модификации (W3C, MediaStreamTrack Insertable Media Processing). Оба подхода помещают ваш код в нужное место: после захвата сигнала, на уровне сырых сэмплов, но до передачи в Opus-энкодер. Это точка вставки B на Рис. 1, и именно сюда должен быть подключён любой пользовательский подавитель шума.

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

Обвязка RNNoise в браузере: паттерн AudioWorklet

Самый чистый пример встраивания собственного подавителя шума в WebRTC-звонок – это RNNoise в AudioWorklet, и он не является теоретическим: именно так реализовано шумоподавление в open-source платформе конференций Jitsi Meet. Анализ их подхода позволяет увидеть все ключевые компоненты.

RNNoise – крошечный open-source подавитель шума, написанный на языке C. Чтобы запустить его в браузере, его компилируют в WebAssembly – обычно сокращают до WASM – формат, позволяющий небраузерному коду, например написанному на C, работать почти с нативной скоростью прямо в веб-странице (Jitsi, 2022). Скомпилированный модуль занимает несколько сотен килобайт – достаточно мало, чтобы загружаться мгновенно.

Причина, по которой он используется в AudioWorklet, а не в старом звуковом коде, – отзывчивость. Ранний браузерный узел обработки звука работал в главном потоке – том же, что отвечает за отображение страницы и обработку кликов, – поэтому любые сбои в интерфейсе могли искажать аудио. AudioWorklet работает в отдельном выделенном звуковом потоке, так что обработка звука не зависит от активности остальной части страницы (W3C, Web Audio API). Jitsi перешёл от старого подхода, основанного на главном потоке, к AudioWorklet именно потому, что при изменении аудио, а не просто его измерении, любая задержка или заикание становятся слышимыми (Jitsi, 2022).

Здесь есть один важный арифметический расчёт, с которым сталкивается каждая команда, и его стоит привести, потому что он объясняет реальный объём работы по интеграции. AudioWorklet передаёт вашему коду аудио фиксированными блоками по 128 сэмплов за раз – изменить этот размер нельзя (W3C, Web Audio API). RNNoise, в свою очередь, требует обработки 480 сэмплов за вызов (Jitsi, 2022). При стандартной частоте дискретизации WebRTC в 48 000 сэмплов в секунду эти числа переводятся во времени следующим образом:

128 сэмплов ÷ 48 000 сэмплов/с = 0,00267 с ≈ 2,67 мс  (что отдаёт worklet)
480 сэмплов ÷ 48 000 сэмплов/с = 0,01000 с = 10,0 мс   (что хочет RNNoise)

Блок, который отдаёт браузер (2,67 мс), короче, чем блок, необходимый модели (10 мс), поэтому нельзя просто передавать каждый блок напрямую в RNNoise. Решение – буфер-накопитель, называемый кольцевым буфером: вы собираете небольшие блоки по 128 сэмплов, пока не наберётся 480, затем отправляете их в RNNoise для очистки, после чего передаёте обработанное аудио дальше, оставляя остаток сэмплов на следующий цикл (Jitsi, 2022). Как только worklet выдаёт очищенный звук, вы заменяете им исходную микрофонную дорожку, и далее звонок продолжается как обычно: Opus кодирует чистый звук, и все замечают разницу.

// Набросок: пропустить микрофон через AudioWorklet шумоподавления и отправить чистую дорожку.
const ctx = new AudioContext({ sampleRate: 48000 });
await ctx.audioWorklet.addModule('rnnoise-worklet.js'); // ваш скомпилированный WASM + worklet
const mic = await navigator.mediaDevices.getUserMedia({
  audio: { noiseSuppression: false, echoCancellation: true } // встроенное NS ВЫКЛ — см. ниже
});
const source = ctx.createMediaStreamSource(mic);
const denoiser = new AudioWorkletNode(ctx, 'rnnoise-processor');
const sink = ctx.createMediaStreamDestination();
source.connect(denoiser).connect(sink);
const cleanTrack = sink.stream.getAudioTracks()[0]; // эту дорожку отправляем по peer connection

Частая ошибка: два подавителя сразу

Присмотритесь к коду выше – там написано noiseSuppression: false. Это не опечатка: это самая важная строка, и ошибка в ней – самая частая во всей теме.

Ловушка – двойное подавление. Если оставить встроенный подавитель шума в браузере включённым и запустить свою модель, аудиосигнал проходит через два подавителя подряд. Это хуже, чем использование любого из них по отдельности, по двум причинам. Во-первых – впустую потраченные вычисления: вы платите двойную цену за одну и ту же работу, что быстро разряжает батареи ноутбуков и вызывает лаги на телефонах. Во-вторых – ухудшенное качество звука: современные модели шумоподавления обучены на «сырых», необработанных аудиоданных, и подача им сигнала, уже изменённого другим подавителем, сбивает их работу и может привести к странному, «перегруженному» результату. LiveKit, лицензирующий модели шумоподавления для своей платформы, прямо формулирует это правило в документации: не применяйте модель шумоподавления к аудио, которое уже обработала другая модель, поскольку они обучены на исходных данных и иначе могут вести себя непредсказуемо (LiveKit, 2026).

Решение – простая дисциплина: ровно один подавитель шума в аудиотракте. Когда отправляете свою модель, ставьте noiseSuppression: false, чтобы встроенный подавитель браузера отключился. Если используете встроенный – не добавляйте свою модель дополнительно. Эхоподавление и автоматическая регулировка усиления – отдельные задачи, которые обычно можно оставлять включёнными: правило – один шумоподавитель, а не один аудиопроцесс в целом. (Эхоподавление – смежная, но отдельная проблема, подробнее – в нашей статье про эхоподавление в WebRTC.)

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

DeepFilterNet в браузере: проблема веса

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

Обычный способ запустить DeepFilterNet в браузере – использовать ML-рантайм ONNX Runtime Web, который сам по себе занимает около 11,8 мегабайта до загрузки модели – это значительная нагрузка по сравнению с несколькими сотнями килобайт, которые занимает RNNoise. Исторически у ONNX Runtime Web также возникали проблемы с работой внутри AudioWorklet – ключевой среды для обработки аудио в реальном времени. Чтобы обойти эти ограничения, команды используют вручную собранные WebAssembly-версии, которые значительно легче, и рабочие интеграции DeepFilterNet для WebRTC-клиентов уже существуют. Однако их внедрение требует больше инженерных усилий, чем в случае с RNNoise.

Практический подход в 2026 году: используйте RNNoise в формате WASM, если нужна бесплатная модель, полностью загружаемая в браузер, и рассматривайте DeepFilterNet, только если его более высокое качество оправдывает дополнительный объём – либо запускайте его на сервере, где размер модели уже не имеет значения. Подробное сравнение двух моделей по качеству и задержке – см. статью про модели.

Клиент или сервер: выбирайте по тому, чем вы управляете

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

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

Работа на сервере становится необходимой, когда вы не контролируете исходное устройство. Самый очевидный пример – обычная телефонная сеть: когда кто-то звонит в ваш сервис с обычного телефона через протокол SIP, который инженеры называют мостом между интернет-звонками и телефонными линиями, на его стороне нет браузера, чтобы запустить модель. Поэтому единственная возможность обработать это аудио – на вашем сервере. Та же логика применима и к голосовым ИИ-агентам: бот, подключающийся к звонку для транскрибации или ответов, получает аудио из разных источников, и проще всего очистить его централизованно – на входе. Чистое аудио напрямую повышает точность живых субтитров и транскрипции. Сервер также обеспечивает единое место для контроля качества и обновления моделей – за счёт процессорного времени, которое теперь тратится на каждый поток. Тяжёлые GPU-движки, такие как аудиоэффекты NVIDIA Maxine, работают здесь: они обрабатывают аудио на серверных видеокартах до того, как оно попадёт в транскрипцию или воспроизведение (NVIDIA, 2026).

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

Krisp AI: Управляемый путь в WebRTC

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

Krisp – компания по разработке голосового ИИ, основанная в 2017 году в Беркли, Калифорния. Её программное обеспечение для шумоподавления работает полностью на устройстве: по утверждению самой компании, аудиоданные никогда не загружаются на её серверы (Krisp, 2026). Технология Krisp используется в Discord, RingCentral и Zoho, а также через партнёрства – в платформах Twilio и Daily; в 2025 году компания сообщила о годовой выручке около $37,7 млн (getLatka, 2026).

Krisp поставляется в виде SDK – набора инструментов для разработки, готовой библиотеки кода, которую разработчики могут интегрировать в свои приложения. Поддерживается Windows, macOS, Linux, Android, iOS и браузеры – последние через сборку на WebAssembly. В реальном времени обработка добавляет задержку примерно в 25 миллисекунд для стандартной модели и около 15 миллисекунд для упрощённой, что остаётся в допустимых пределах для комфортного общения (Krisp, 2026).

Как он подключается к WebRTC, зависит от слота. В браузере Krisp устанавливается как аудиопроцессор на микрофонную дорожку до отправки аудио – та же точка вставки B, что и у RNNoise, только управляемая автоматически. LiveKit, например, передаёт Krisp через однострочный track processor в своём web SDK:

// Управляемый фильтр Krisp от LiveKit: цепляем к локальной микрофонной дорожке до публикации.
const { KrispNoiseFilter } = await import('@livekit/krisp-noise-filter');
const krisp = KrispNoiseFilter();
await localAudioTrack.setProcessor(krisp);   // чистит исходящее аудио в браузере
await krisp.setEnabled(true);

На сервере Krisp работает внутри платформы: Twilio загружает Krisp SDK вместе со своим Voice JS SDK и запускает его как этап предварительной обработки между микрофоном и аудиоэнкодером, а LiveKit и другие платформы применяют его к входящему аудио для ИИ-агентов и активируют на телефонном шлюзе одним флагом krisp_enabled: true для SIP-звонков (Twilio, 2026; LiveKit, 2026).

Самая полезная способность Krisp для конференций в 2026 году – вторая модель под названием background voice cancellation, или BVC. Обычное шумоподавление устраняет неречевые звуки – шум вентиляторов, трафик, стук по клавиатуре – но сохраняет все голоса. BVC работает глубже: она убирает чужие голоса, оставляя только основного говорящего. Это особенно важно в open-space и при работе с голосовыми ИИ-агентами, где иначе коллега, говорящий рядом, может быть ошибочно распознан как сам говорящий. Улучшение измеримо: в опубликованном тесте LiveKit исходное шумное аудио дало word-error rate транскрипции 117,6 процента (что хуже бесполезного – в транскрипции больше ошибок, чем слов), тогда как модель BVC от Krisp снизила этот показатель до 23,5 процента, а конкурирующий движок ai-coustics достиг 7,1 процента (LiveKit, 2026). Урок двойной: такие модели действительно работают, и серьёзных поставщиков теперь не один – Krisp остаётся самым известным, но уже не единственным управляемым решением.

RNNoise WASM против Krisp AI: Build vs Buy для WebRTC

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

Читайте как руководство к эксплуатации, а не как турнирную таблицу. RNNoise WASM бесплатен и полностью ваш – вы сами компилируете его, интегрируете с AudioWorklet, управляете буферизацией и принимаете его пределы качества при сильном шуме. Krisp (а теперь и ai-coustics) стоит денег, но обеспечивает боеспособное качество на всех платформах, умеет удалять чужие голоса и не требует поддержки – модель обновляет вендор, а не вы. Сравнение брендов – Krisp против NVIDIA Maxine и Dolby – в контексте выбора между разработкой и покупкой решения – это отдельная тема, подробно рассмотренная в нашей статье Krisp vs Maxine vs Dolby. Здесь же правило простое: если вы работаете только в браузере и шум не экстремальный, RNNoise WASM – самый дешёвый и надёжный выбор. Как только нужны все платформы, поддержка звонков или удаление чужих голосов, управляемый движок оправдывает свою цену.

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

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

Мы разрабатываем WebRTC-продукты, которым критически важна чистая, естественная аудиозапись – платформы видеоконференций, телемедицинские консультации, где врач должен чётко слышать каждое слово, e-learning-классы и ИИ-инструменты для анализа встреч. В этой сфере важнее не имя модели, а правильный выбор интеграции.

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

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

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

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

• У WebRTC-шумоподавления три варианта: встроенное, собственное до кодирования и серверное.
• Для шумоподавления требуется необработанное аудио – размещайте его до Opus, а не в Encoded Transform.
• Собственные модели работают в AudioWorklet, вне основного потока; RNNoise компилируется в WASM.
• Никогда не используйте два шумоподавителя одновременно – применяйте noiseSuppression: false со своей моделью.
• Обработка на стороне клиента подходит для пользователей браузеров; на сервере – для звонков и ИИ-агентов.
• Krisp AI – управляемое решение; его модель BVC подавляет не только шум, но и чужие голоса.

Что Почитать Далее

• Модели шумоподавления в реальном времени – Krisp, RNNoise, DeepFilterNet
• Бюджет задержки real-time ИИ ниже 100 мс
• WebRTC + AI: Insertable Streams, 100ms и сравнение video SDK