Эти вещи о звуке серии WebRTC

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

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

Звуковой движок в основном включает в себя: модуль аудиоустройства ADM, фабрику аудиокодера, фабрику аудиодекодера, микшерный микшер, APM для предварительной обработки звука.

Как работает звук

Если вы хотите систематически понять звуковой движок, вам сначала нужно понять основные классы реализации и поток аудиоданных, а затем мы кратко проанализируем его.

Диаграмма основных классов звукового движка:

Звуковой движок WebrtcVoiceEngine в основном включает в себя модуль аудиоустройства AudioDeviceModule, аудиомикшер AudioMixer, аудиопроцессор 3A AudioProcessing, класс управления аудио AudioState, фабрику аудиокодера AudioEncodeFactory, фабрику аудиодекодера AudioDecodeFactory, а голосовой медиаканал включает отправку и получение. .

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

2. Аудиомикшер AudioMixer в основном отвечает за микширование данных передачи звука (сбор данных устройства и микширование звука), микширование данных воспроизведения звука (многоканальный прием звука и микширование звука).

3. Процессор Audio 3A AudioProcessing в основном отвечает за предварительную обработку данных аудио, включая эхоподавление AEC, автоматическую регулировку усиления AGC и подавление шума NS. APM делится на два потока: один поток на ближнем конце и один поток на дальнем конце. Поток на ближнем конце относится к входящим данным с микрофона, поток на дальнем конце относится к принятым данным.

4. Класс управления аудио AudioState включает в себя модуль аудиоустройства ADM, модуль предварительной обработки аудио APM, аудиомикшер Mixer и центр потока данных AudioTransportImpl.

5. Фабрика кодировщиков аудио AudioEncodeFactory содержит такие кодеки, как Opus, iSAC, G711, G722, iLBC, L16 и т. д.

6. Audio Decoder Factory AudioDecodeFactory содержит Opus, iSAC, G711, G722, iLBC, L16 и другие кодеки.

Аудио рабочий процесс:


1. Инициатор собирает звук через микрофон

2. Инициатор отправляет собранный звуковой сигнал в модуль APM для эхоподавления AEC, шумоподавления NS и обработки автоматической регулировки усиления AGC.

3. Инициатор отправляет обработанные данные кодировщику для сжатия и кодирования голоса.

4. Инициатор отправляет закодированные данные через модуль передачи RtpRtcp, и передает их получателю через Интернет.

5. Принимающая сторона принимает аудиоданные, передаваемые из сети, и сначала передает их в модуль NetEQ для устранения джиттера, декодирования сокрытия потери пакетов и т. д.

6. Принимающая сторона отправляет обработанные аудиоданные на устройство звуковой карты для воспроизведения.

Модуль NetEQ является основным модулем речевого движка Webrtc.

В модуле NetEQ он примерно разделен на модуль MCU и модуль DSP. MCU в основном отвечает за расчет и статистику задержки и джиттера, а также генерирует соответствующие команды управления. Модуль DSP отвечает за прием и обработку соответствующих пакетов данных в соответствии с управляющими командами MCU и их передачу на следующую ссылку.

поток аудиоданных

В соответствии с описанным выше рабочим процессом аудио, мы продолжим совершенствовать поток данных аудио. Основное внимание будет уделено важной роли, которую играет центр передачи данных AudioTransportImpl во всем звене.

Центр передачи данных AudioTransportImpl реализует интерфейс обработки данных сбора данных RecordDataIsAvailbale и интерфейс обработки данных воспроизведения NeedMorePlayData. RecordDataIsAvailbale отвечает за обработку захвата аудиоданных и их распространение на все отправляющие потоки. NeedMorePlayData отвечает за микширование всех полученных потоков, затем подачу их в APM в качестве эталонного сигнала для обработки и, наконец, передискретизацию его до запрошенной выходной частоты дискретизации.

Основной внутренний процесс RecordDataIsAvailbale:

  1. Аудиоданные, собранные аппаратным обеспечением, напрямую передискретизируются с частотой дискретизации отправки.
  2. 3A обработка аудиоданных после передискретизации с помощью предварительной обработки аудио.
  3. VAD-обработка
  4. Цифровое усиление регулирует объем сбора данных
  5. Внешний обратный вызов аудиоданных для внешней предварительной обработки
  6. Все аудиоданные, которые должны быть отправлены отправителем микширования, включая собранные данные и данные сопровождающего звука
  7. Рассчитать энергетическую ценность аудиоданных
  8. Распространить его на все отправляющие потоки
Внутренние основные процессы NeedMorePlayData:
  1. Смешайте аудиоданные из всех полученных потоков
1.1 Расчет частоты дискретизации выходного сигнала CalculateOutputFrequency()
1.2 Соберите аудиоданные из источника GetAudioFromSources(), выберите три канала без отключения звука и наибольшей энергии для микширования
1.3 Выполнение операции микширования FrameCombiner::Combine()
  1. При определенных условиях шумовая инжекция выполняется для стороны сбора данных в качестве опорного сигнала.
  2. Микширование локального звука
  3. Цифровое усиление регулирует громкость воспроизведения
  4. Внешний обратный вызов аудиоданных для внешней предварительной обработки
  5. Рассчитать энергетическую ценность аудиоданных
  6. Передискретизируйте звук до частоты дискретизации запрошенного вывода.
  7. Отправлять аудиоданные в APM в качестве эталонного сигнала для обработки
Исходя из потока данных на рисунке выше, почему вам нужны FineAudioBuffer и AudioDeviceBuffer? Поскольку аудиоконвейер WebRTC поддерживает обработку данных только за 10 мс, разные платформы операционных систем предоставляют аудиоданные с разной продолжительностью сбора и воспроизведения, а разные частоты дискретизации также предоставляют данные разной продолжительности. Например, в iOS частота дискретизации 16K обеспечит 128 кадров аудиоданных по 8 мс, частота дискретизации 8K обеспечит 128 кадров аудиоданных по 16 мс, частота дискретизации 48K обеспечит 512 кадров аудиоданных по 10,67 мс.

Данные, воспроизводимые и собираемые AudioDeviceModule, всегда принимаются или отправляются через AudioDeviceBuffer с 10 мс аудиоданных. Для платформ, которые не поддерживают сбор и воспроизведение аудиоданных длительностью 10 мс, FineAudioBuffer также будет вставлен в модули AudioDeviceModule и AudioDeviceBuffer платформы для преобразования формата аудиоданных платформы в аудиокадры длительностью 10 мс, которые может обрабатывать WebRTC. В AudioDeviceBuffer количество точек дискретизации и частота дискретизации, соответствующие аудиоданным с текущего аппаратного устройства, будут регулярно подсчитываться в течение 10 секунд, что можно использовать для определения рабочего состояния текущего аппаратного обеспечения.

Изменения, связанные со звуком

  1. Аудиопрофиль реализован, поддерживает 2 сценария VoIP и MUSIC и реализует комплексную техническую стратегию частоты дискретизации, скорости кодирования, режима кодирования и количества каналов. В iOS реализовано разделение потоков сбора и воспроизведения, поддерживается двухканальное воспроизведение.
  2. Совместимость схемы доставки и адаптации параметров аудио 3А.
  3. Адаптация сцены гарнитуры, адаптация гарнитуры Bluetooth и обычной гарнитуры, а также адаптация динамического переключения 3A.
  4. Алгоритм введения шума Noise_Injection в качестве опорного сигнала играет особенно очевидную роль в подавлении эха в сценариях с наушниками.
  5. Поддержка локального аудиофайла и сетевого аудиофайла http&https.
  6. Реализация Audio Nack улучшает способность защиты аудио от потери пакетов и в настоящее время выполняет внутриполосную FEC.
  7. Оптимизация обработки звука для одиночного и двойного разговора.
  8. Исследования IOS по встроенной АРУ:
(1) Встроенная АРУ эффективна для речи и музыки, но не влияет на шум и минимальный уровень шума окружающей среды.

(2) Усиление аппаратного микрофона разных моделей разное, iPhone 7 Plus > iPhone 8 > iPhone X, поэтому при отключении программной и аппаратной АРУ уровень звука на дальнем конце будет разным.

(3) В дополнение к переключаемой АРУ, предоставляемой iOS, есть также АРУ, которая будет работать все время для точной настройки уровня сигнала; я предполагаю, что эта АРУ, которая всегда работает, является аналоговой АРУ, поставляемой с iOS. , который может быть связан с оборудованием и не имеет API.

(4) На большинстве моделей iOS входная громкость будет уменьшена во внешнем режиме «после повторного подключения наушников». Текущее решение состоит в том, чтобы добавить preGain, чтобы вернуть входную громкость в нормальное состояние после повторного подключения наушников.

Устранение неполадок со звуком

Позвольте мне поделиться с вами некоторыми из наиболее распространенных явлений и причин звука:



Категории