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

Версия 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 и /system/etc . В следующих примерах показана простая конфигурация политики аудио в формате XML для Android 12 и версий ниже Android 12.

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

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

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

Файловые включения

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

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

Используйте включает, чтобы избежать копирования стандартной информации о конфигурации звукового модуля HAL проекта с открытым исходным кодом Android (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

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

Выпускается в двух вариантах: настраивается и по умолчанию. Для информации о том , как выбрать версию, см Конфигурация с помощью параметра Framework .

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

Конфигурация с использованием Parameter Framework

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

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

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

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

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

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

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

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

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

Более подробную информацию о перечислении и Selection 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 автоматически понижает микширование контента до стерео при отправке на аудиоустройство, которое не поддерживает многоканальный звук.

Медиа кодеки

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