Настройка политик аудио

В выпуске Android 10 реализована существенная переработка диспетчера политик аудио, что обеспечивает большую гибкость для поддержки сложных вариантов использования в автомобильной промышленности:

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

В Android 7.0 представлен формат файла конфигурации аудиополитики (XML) для описания топологии звука.

В предыдущих версиях Android для объявления аудиоустройств, имеющихся в вашем устройстве, требовалось использовать device/<company>/<device>/audio/audio_policy.conf (пример этого файла для аудиооборудования Galaxy Nexus можно найти в device/samsung/tuna/audio/audio_policy.conf ). Однако CONF — это простой, проприетарный формат, слишком ограниченный для описания сложных топологий для таких вертикалей, как телевизоры и автомобили.

В Android 7.0 файл audio_policy.conf объявлен устаревшим и добавлена ​​поддержка определения топологии звука с помощью XML-файла, который более удобен для восприятия человеком, имеет широкий набор инструментов для редактирования и анализа и достаточно гибок для описания сложных топологий звука. В Android 7.0 используется флаг сборки USE_XML_AUDIO_POLICY_CONF для выбора XML-формата файлов конфигурации.

Преимущества формата XML

Как и файл CONF, XML-файл позволяет определить количество и типы профилей выходных и входных потоков, устройства, используемые для воспроизведения и захвата, а также аудиоатрибуты. Кроме того, формат XML предлагает следующие улучшения:

  • В Android 10 разрешена одновременная работа более одного активного приложения для записи.
    • Начало записи никогда не отклоняется из-за ситуации параллелизма.
    • Функция обратного вызова registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) уведомляет клиентов об изменении пути захвата.
  • В следующих ситуациях клиент получает тихие аудиофрагменты:
    • Активен вариант использования, чувствительный к конфиденциальности (например, VOICE_COMMUNICATION ).
    • У клиента нет приоритетной службы или приоритетного пользовательского интерфейса.
    • Особые роли признаются политикой:
      • Служба доступности: может записывать, даже если активен сценарий использования, чувствительный к конфиденциальности.
      • Помощник: считается нарушающим конфиденциальность, если пользовательский интерфейс находится поверх остальных.
  • Аудиопрофили имеют структуру, похожую на простые аудиодескрипторы HDMI, что позволяет использовать разные наборы частот дискретизации/масок каналов для каждого аудиоформата.
  • Существуют явные определения всех возможных соединений между устройствами и потоками. Ранее неявное правило позволяло подключать все устройства, подключенные к одному модулю HAL, что не позволяло аудиополитике контролировать соединения, запрашиваемые через API аудиопатчей. В формате XML описание топологии определяет ограничения на соединения.
  • Поддержка включений позволяет избежать повторения стандартных определений A2DP, USB или перенаправления отправки.
  • Кривые объёма можно настраивать. Ранее таблицы объёма были жёстко заданы в коде. В формате XML таблицы объёма описаны и могут быть настроены.

Шаблон frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml демонстрирует использование многих из этих функций.

Формат и местоположение файла

Новый файл конфигурации аудиополитики — audio_policy_configuration.xml , расположенный в /system/etc . В следующих примерах показана простая конфигурация аудиополитики в формате XML для Android 12 и версий ниже Android 12.

Структура верхнего уровня содержит модули, соответствующие каждому аппаратному модулю аудио HAL, где каждый модуль имеет список портов микширования, портов устройств и маршрутов:

  • Микширующие порты описывают возможные профили конфигурации потоков, которые можно открыть в аудио HAL для воспроизведения и захвата.
  • Порты устройств описывают устройства, которые можно подключить, их тип (а также, при необходимости, адрес и аудиосвойства).
  • Маршруты отделены от дескриптора смешанного порта, что позволяет описывать маршруты от устройства к устройству или от потока к устройству.

Таблицы громкости — это простые списки точек, определяющих кривую, используемую для перевода индекса пользовательского интерфейса в громкость в дБ. Отдельный включаемый файл содержит кривые по умолчанию, но каждую кривую для конкретного варианта использования и категории устройства можно перезаписать.

Включения файлов

Метод XML Inclusions (XInclude) можно использовать для включения информации о конфигурации аудиополитики, находящейся в других XML-файлах. Все включаемые файлы должны соответствовать описанной выше структуре со следующими ограничениями:

  • Файлы могут содержать только элементы верхнего уровня.
  • Файлы не могут содержать элементы XInclude.

Используйте include, чтобы избежать копирования информации о стандартных конфигурациях аудиомодулей HAL проекта Android Open Source Project (AOSP) во все файлы конфигурации аудиополитики (что подвержено ошибкам). Стандартный XML-файл конфигурации аудиополитики предоставляется для следующих аудиомодулей HAL:

  • A2DP: a2dp_audio_policy_configuration.xml
  • Перенаправить субмикс: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

Организация кода аудиополитики

AudioPolicyManager.cpp разделён на несколько модулей для удобства обслуживания и настройки. Структура frameworks/av/services/audiopolicy включает следующие модули.

Модуль Описание
/managerdefault Включает универсальные интерфейсы и реализацию поведения, общие для всех приложений. Аналогично AudioPolicyManager.cpp , но с абстрагированным функционалом движка и общими концепциями.
/common Определяет базовые классы (например, структуры данных для профилей входного и выходного аудиопотока, дескрипторов аудиоустройств, аудиопатчей и аудиопортов). Ранее это было определено в AudioPolicyManager.cpp .
/engine

Реализует правила, определяющие, какое устройство и тома следует использовать для конкретного сценария использования. Реализует стандартный интерфейс с общей частью, например, для получения подходящего устройства для конкретного сценария воспроизведения или захвата, а также для установки подключенных устройств или внешнего состояния (то есть состояния вызова с принудительным использованием), которое может изменить решение о маршрутизации.

Доступно в двух версиях: настраиваемой и по умолчанию . Информацию о выборе версии см. в разделе «Настройка с использованием структуры параметров» .

/engineconfigurable Реализация механизма политик, основанная на фреймворке параметров (см. ниже). Конфигурация основана на фреймворке параметров, а политика определяется XML-файлами.
/enginedefault Реализация механизма политик основана на предыдущих реализациях Android Audio Policy Manager. Она используется по умолчанию и включает жёстко заданные правила, соответствующие реализациям Nexus и AOSP.
/service Включает в себя интерфейсы связывания, потоковую передачу и реализацию блокировки с интерфейсом для остальной части фреймворка.

Конфигурация с использованием структуры параметров

Код аудиополитики организован таким образом, чтобы упростить понимание и поддержку, а также поддерживать аудиополитику, полностью определяемую файлами конфигурации. Организация и дизайн аудиополитики основаны на Intel Parameter Framework — платформе для обработки параметров на основе плагинов и правил.

Использование настраиваемой звуковой политики позволяет OEM-производителям:

  • Опишите структуру системы и ее параметры в формате XML.
  • Напишите (на C++) или повторно используйте бэкэнд (плагин) для доступа к описанным параметрам.
  • Определить (в XML или на предметно-ориентированном языке) условия/правила, при которых заданный параметр должен принимать заданное значение.

AOSP включает пример файла конфигурации аудиополитики, использующего фреймворк параметров ( Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Подробные сведения см. в документации Intel по фреймворку параметров .

В Android 10 и более ранних версиях настраиваемая политика аудио выбирается с помощью параметра сборки USE_CONFIGURABLE_AUDIO_POLICY . В Android 11 и более поздних версиях версия движка политики аудио выбирается в файле audio_policy_configuration.xml . Чтобы выбрать настраиваемый движок политики аудио, установите значение configurable для атрибута engine_library элемента globalConfiguration , как configurable в следующем примере:

<audioPolicyConfiguration>
    <globalConfiguration engine_library="configurable" />
...
</audioPolicyConfiguration>

API маршрутизации аудиополитик

В Android 6.0 представлен общедоступный API перечисления и выбора, который располагается поверх инфраструктуры аудиопатчей/аудиопортов и позволяет разработчикам приложений указывать предпочтения для конкретного выхода или входа устройства для подключенных аудиозаписей или дорожек.

В Android 7.0 API Enumeration and Selection проверено тестами CTS и расширено, чтобы включить маршрутизацию для нативных аудиопотоков C/C++ (OpenSL ES). Маршрутизация нативных потоков по-прежнему осуществляется на Java, с добавлением интерфейса AudioRouting , который заменяет, объединяет и делает устаревшими явные методы маршрутизации, специфичные для классов AudioTrack и AudioRecord .

Подробную информацию об API перечисления и выбора см. в разделах «Интерфейсы конфигурации Android» и OpenSLES_AndroidConfiguration.h . Подробную информацию о маршрутизации аудио см. в разделе «AudioRouting» .

Многоканальная поддержка

Если ваше оборудование и драйвер поддерживают многоканальное аудио через HDMI, вы можете вывести аудиопоток напрямую на аудиооборудование (это минует микшер AudioFlinger, поэтому аудиопоток не будет разделен на два канала). HAL аудио должен указывать, поддерживает ли профиль выходного потока поддержку многоканального аудио. Если HAL предоставляет такую ​​возможность, менеджер политик по умолчанию разрешает многоканальное воспроизведение через HDMI. Подробности реализации см. в файле device/samsung/tuna/audio/audio_hw.c .

Чтобы указать, что ваш продукт содержит многоканальный аудиовыход, отредактируйте файл конфигурации аудиополитики, описав его. В следующем примере из frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml показана динамическая маска канала. Это означает, что менеджер аудиополитики запрашивает маски каналов, поддерживаемые HDMI-приемником после подключения.

Вы также можете указать статическую маску канала, например, AUDIO_CHANNEL_OUT_5POINT1 . Микшер AudioFlinger автоматически понижает качество звука до стерео при отправке на аудиоустройство, не поддерживающее многоканальное аудио.

Медиа-кодеки

Убедитесь, что аудиокодеки, поддерживаемые вашим оборудованием и драйверами, правильно заявлены для вашего продукта. Подробнее см. в разделе «Предоставление кодеков в фреймворк» .