При разработке сервиса для диагностики звуков двигателей через браузер выяснилось, что стандартные функции улучшения звука (getUserMedia) работают непредсказуемо. Вместо того чтобы просто убирать фоновый шум, программные алгоритмы могут катастрофически снижать амплитуду полезного сигнала или, наоборот, некорректно интерпретировать тишину.
Анализ показал, что проблема кроется не в версии операционной системы или конкретном браузере, а в реализации звуковых драйверов производителями устройств. В Android ситуация разнится от модели к модели: на одних устройствах шумоподавление работает корректно, а на других — «душит» звук, превращая каждую десятую запись в практически неслышный шум. При этом бюджетные смартфоны не являются главной причиной проблем; среди флагманов и устройств среднего сегмента разброс параметров записи оказывается не менее значительным.
Ситуация с iOS выглядит иначе. Отключение обработки звука в Safari приводит к резкому падению уровня сигнала на 18 дБ. Это означает, что система не просто вычитает шум, а снижает общее усиление всего аудиопотока, включая полезный сигнал. Это делает невозможным корректную работу алгоритмов, которые полагаются на стабильный уровень громкости для анализа звуковых паттернов.
Главный вывод исследования заключается в том, что программные механизмы WebRTC, предназначенные для улучшения качества голоса при разговоре, непригодны для записи стационарного широкополосного шума. Когда объектом записи является не голос, а фоновый звук (например, работа двигателя), автоматическое подавление шума и автоусиление превращают данные в бесполезный мусор, искажая реальную картину происходящего.
Для разработчиков приложений, работающих со звуком через веб-интерфейсы, это означает необходимость обязательной проверки настроек audio context. Использование стандартных флагов echoCancellation, noiseSuppression и autoGainControl без контроля может привести к тому, что нейросеть или алгоритм получат на вход искаженные данные, которые ошибочно примут за неисправность устройства.
