Пролог
Практически во всех приложениях, которые мы используем для связи в реальном времени, то есть для звонков, предлагается некоторый уровень шумоподавления. Это связано с тем, что Интернет наполнен чрезвычайно разнородными устройствами с микрофонами самых разных конфигураций. Таким образом, все это вносит разный уровень нежелательных частот и шумов в поток webRTC, который используют эти приложения.
Таким образом, подавление шума на уровне «голых костей» будет просто отключением этих нежелательных частот, а на самом высоком уровне - просто удержанием голоса предполагаемого пользователя в потоке и удалением всего остального.
Неоднородность Интернета не перестает быть проблемой - тот факт, что ваше приложение могут использовать люди с ноутбуком за 500 долларов или полностью загруженным MacBook Pro, не помогает!
У большинства приложений теперь есть два варианта: надейтесь, что ваши пользователи не используют картошку для видео / голосовых вызовов, ИЛИ потратите немного денег на решение проблемы и выполните снижение шума в своем потоке, пока поток находится в пути.
Дорогой маршрут
Последний вариант выглядит заманчивым, на самом деле его использует Google Meet. Когда вы участвуете в вызове Google Meet, ваш голос отправляется с вашего устройства в центр обработки данных, где он проходит через модель машинного обучения на TPU, повторно шифруется, а недавно измененные данные вводятся обратно в поток. . (Мультимедиа всегда шифруется во время транспортировки, даже при перемещении в пределах собственных сетей, компьютеров и центров обработки данных Google. Есть два исключения: когда вы звоните по традиционному телефону и когда записывается встреча.) Легко представить, что это может очень быстро пойти на спад, добавив дополнительную задержку, если он не реализован правильно, или вызовет большие расходы за [1] TPU
В то время как у Google есть все ресурсы, как финансовые, так и инженерные, для решения этой проблемы, стартап, находящийся на ранних этапах разработки, скорее всего, этого не сделает.
Прагматический путь
Теперь у нас остается вариант 2, подобные которому используются такими компаниями, как krisp.ai и voice-ping.com вместе с большинством других известных приложений RTC - они используют локальные ресурсы пользователя для снижения шума, и у большинства из них есть возможность масштабирования агрессивности фильтра в зависимости от того, используют ли они картошку или MacBook Pro. Эта агрессивность фильтрации может выражаться в самых разных вещах, от простого увеличения размера буфера, в котором мы выполняем пакетные вычисления, или, на самом базовом уровне, просто от множества подключаемых узлов фильтра.
Следующий...
В следующих частях мы рассмотрим методологии реализации, как основные, так и довольно продвинутые способы достижения этой цели, а также способы, с помощью которых мы можем (в некоторой степени) решать проблемы, которые я только что упомянул выше.
