Проблема: фоновый шум в мобильных звонках
При открытии микрофона через AVAudioSession на iOS или AudioRecord на Android вы получаете сырой PCM-поток — со всем, что находится вокруг пользователя. Строительные работы, кофемашина, дети — всё это идёт в вызов. Стандартный Acoustic Echo Cancellation (AEC) из WebRTC убирает эхо, но не фоновый шум. Мы реализуем интеграцию ML-моделей шумоподавления под ключ — от выбора архитектуры до публикации в сторах. Наши инженеры имеют 5+ лет опыта в аудиообработке и реализовали более 30 проектов с голосовыми интерфейсами.
Чем отличается AI-шумоподавление от стандартного DSP
Классический подход — спектральное вычитание или Wiener filter: модель шума оценивается в паузах речи, затем вычитается из спектра. Работает для стационарного шума (гул вентилятора), ломается на нестационарном (голос в метро, клавиатура рядом).
AI-подход — нейросеть, обученная на парах «чистая речь + шумная речь», предсказывает маску для каждого фрейма спектрограммы. Модели уровня RNNoise или DTLN работают в реальном времени, обрабатывая 10–20 мс фреймы с латентностью менее одного фрейма.
Как работает AI-шумоподавление в реальном времени?
ML-модель получает спектрограмму сигнала, вычисляет вероятность наличия речи в каждом частотном баке и применяет фильтр. Это позволяет подавлять шум даже когда человек говорит — в отличие от гейтов. Voice Activity Detection (VAD) дополнительно снижает нагрузку, пропуская только речевые фрагменты.
Сравнение моделей: RNNoise vs DTLN
| Параметр | RNNoise | DTLN |
|---|---|---|
| Размер модели | ~90 КБ | ~2 МБ |
| Задержка | <1 мс | 8–35 мс (зависит от устройства) |
| Качество подавления | Хорошее для стационарного шума | Отличное для сложного, многокомпонентного шума |
| Поддержка платформ | C-библиотека (iOS/Android через NDK) | TFLite (Android) / Core ML (iOS) |
| Рекомендация | Бюджетные устройства, лимит по ресурсам | Флагманы, требования к качеству |
RNNoise: быстрый старт на обеих платформах
RNNoise от Mozilla — C-библиотека, 90 KB, ~2 MFLOPS на фрейм. Компилируется в статическую библиотеку для iOS (xcframework) и Android (AAR с нативной частью через NDK).
// Инициализация DenoiseState *st = rnnoise_create(NULL); // Обработка фрейма (480 сэмплов = 10 мс при 48 kHz) float frame[480]; // ... заполнить из буфера микрофона float vad_prob = rnnoise_process_frame(st, frame, frame); // frame теперь содержит очищенный сигнал // vad_prob > 0.5 — вероятно речь Интеграция в iOS: AVAudioEngine с кастомным AVAudioSinkNode или tap на входной ноде. Формат — Float32, 48 kHz, mono. AVAudioSession нужно настроить с mode: .voiceChat и явно отключить системную обработку, иначе iOS применяет собственный noise reduction поверх вашего.
let inputNode = audioEngine.inputNode let format = inputNode.outputFormat(forBus: 0) inputNode.installTap(onBus: 0, bufferSize: 480, format: format) { [weak self] buffer, _ in guard let self = self else { return } let channelData = buffer.floatChannelData![0] // Передаём в rnnoise_process_frame через C-bridge self.rnnoiseProcessor.process(channelData, frameLength: Int(buffer.frameLength)) } На Android — AudioRecord с AudioFormat.ENCODING_PCM_FLOAT, размер буфера 480 сэмплов, обработка в отдельном потоке с Process.THREAD_PRIORITY_URGENT_AUDIO. Через JNI вызываем ту же C-библиотеку.
DTLN и более тяжёлые модели
Если RNNoise недостаточно (сложный многокомпонентный шум, несколько источников), используем DTLN — двухстадийная LSTM-модель. Конвертируется в TFLite (Android) или Core ML (iOS).
На практике: DTLN при 16 kHz занимает 8–14 мс на фрейм на iPhone 12, что укладывается в реальное время. На Android Snapdragon 778G — аналогично. На бюджетных Helio G85 — 25–35 мс, что создаёт накопительную задержку.
Для мобильного применения важен выбор частоты дискретизации: 16 kHz вместо 48 kHz сокращает вычислительную нагрузку вчетверо, а для речи полосы до 8 kHz достаточно для разборчивости.
Интеграция в WebRTC
WebRTC SDK (LiveKit, Agora, Daily) предоставляют AudioProcessingModule или hook до энкодирования. В нативном WebRTC для iOS — кастомный RTCAudioProcessingModule:
// Регистрируем кастомный процессинг let config = RTCConfiguration() // Создаём RTCPeerConnectionFactory с кастомным AudioDeviceModule // или используем AudioProcessingConfig для WebRTC built-in замены Важный нюанс: WebRTC уже содержит AECM и NS (Noise Suppression). При включении собственного AI-шумоподавления нужно отключить встроенный NS через AudioProcessingConfig, иначе двойная обработка создаёт артефакты — «металлический» звук, срезанные согласные.
Что входит в работу (deliverables)
- Аудит текущего аудиопайплайна приложения
- Выбор модели (RNNoise/DTLN/кастомная) под требования по латентности и качеству
- Компиляция нативной библиотеки под целевые архитектуры (arm64, x86_64 для симулятора)
- Интеграция в существующий аудиостек (AVAudioEngine, AudioRecord, WebRTC)
- Настройка VAD и устранение двойной обработки (отключение встроенного NS)
- Тестирование на реальных шумах (метро, улица, офис)
- Предоставление документации и поддержка при публикации в сторах
Типичные ошибки при внедрении
- Забывают отключить встроенный noise suppression в WebRTC — получают «металлический» звук.
- Используют 48 kHz для DTLN — задержка становится неприемлемой.
- Не настраивают VAD — модель тратит ресурсы на тишину.
- Не проверяют совместимость с разными версиями Android (AudioRecord имеет баги на некоторых прошивках).
Ориентиры по срокам
Интеграция RNNoise в существующий WebRTC-стек — 1–2 недели. Реализация с DTLN/TFLite, настройка VAD, поддержка двух платформ — 3–5 недель. Стоимость рассчитывается индивидуально. Свяжитесь с нами для оценки вашего проекта — мы подберем оптимальное решение и предоставим консультацию.