Комбинированная маршрутизация аудиоустройств

Функция комбинированной маршрутизации аудиоустройств добавляет поддержку потоковой передачи звука на несколько аудиоустройств одновременно. Используя эту функцию, привилегированные приложения могут выбирать несколько предпочтительных устройств для конкретной стратегии с помощью системных API. Приложения могут более точно определять возможности аудиоустройств, используя общедоступные API, предоставляемые этой функцией. Для Android версии 11 и ниже реализация аудиоплатформы имеет ограниченную поддержку нескольких аудиоустройств одного типа (например, 2 гарнитур Bluetooth A2DP), подключенных одновременно. Правила маршрутизации звука по умолчанию также не позволяют пользователям выбирать несколько устройств одного типа для данного варианта использования.

Начиная с Android 12, эти ограничения сняты, чтобы обеспечить новые варианты использования, такие как аудиовещание, многоадресная рассылка на группу аудионаушников BLE или одновременный выбор нескольких звуковых карт USB. Одновременная маршрутизация на несколько USB-устройств не поддерживается.

Начиная с Android 14, платформа USB поддерживает маршрутизацию на несколько USB-устройств при условии, что USB-устройства относятся к разным типам аудиоустройств, а также имеется поддержка ядра и поставщика для одновременного подключения нескольких USB-устройств.

На этой странице описано, как реализовать поддержку потоковой передачи звука на несколько аудиоустройств и как проверить реализацию этой функции.

Примечание. Эта функция реализована исключительно в AOSP. Некоторые тесты находятся в GTS, которого нет в AOSP.

Поддержка потоковой передачи звука на несколько аудиоустройств

В Android 12 есть два набора API, которые поддерживают эту функцию:

• Системные API обрабатывают несколько предпочтительных устройств для стратегии.
• Интерфейс HIDL, реализованный поставщиком как часть аудио HAL, сообщает о возможностях устройства.

В следующих разделах каждый из этих API рассматривается более подробно.

Обработка нескольких предпочтительных устройств для стратегии

Диспетчер политики аудио предлагает системные API для лучшей поддержки потоковой передачи звука на несколько аудиоустройств одновременно. Эти системные API позволяют настраивать, получать и удалять несколько предпочтительных устройств для заданной стратегии. До Android 12 эта функция поддерживалась только для одного устройства.

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

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

Аудиоустройство должно быть указано при открытии выходного потока. Активное медиа-устройство — это устройство, используемое при открытии выходных потоков в этом контексте.

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

1. Если все предпочтительные устройства для мультимедиа доступны, все они выбираются в качестве активных устройств.
2. В противном случае выбирается последнее подключенное съемное устройство.
3. Если съемные устройства не подключены, для выбора активных устройств применяются правила политики аудио по умолчанию для выбора устройств вывода.

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

• Выходной поток должен поддерживать активные устройства.
• Выходной поток должен поддерживать динамические профили.
• Выходной поток в данный момент не должен направляться на активные устройства.

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

Диспетчер политики аудио предлагает следующий список системных API (как определено в AudioManager.java ):

• setPreferredDeviceForStrategy

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

• removePreferredDeviceForStrategy

  Удаляет предпочитаемые аудиоустройства, ранее установленные с помощью setPreferredDeviceForStrategy или setPreferredDevicesForStrategy .

• getPreferredDeviceForStrategy

  Возвращает предпочтительное устройство для стратегии аудио, ранее установленной с помощью setPreferredDeviceForStrategy или setPreferredDevicesForStrategy .

• setPreferredDevicesForStrategy

  Устанавливает предпочтительные устройства для данной стратегии.

• getPreferredDevicesForStrategy

  Возвращает предпочтительные устройства для стратегии аудио, ранее заданной с помощью setPreferredDeviceForStrategy или setPreferredDevicesForStrategy .

• OnPreferredDevicesForStrategyChangedListener

  Определяет интерфейс для уведомления об изменениях в предпочтительных аудиоустройствах, настроенных для данной стратегии аудио.

• addOnPreferredDevicesForStrategyChangedListener

  Добавляет прослушиватель для получения уведомлений об изменениях в предпочтительном для стратегии аудиоустройстве.

• removeOnPreferredDevicesForStrategyChangedListener

  Удаляет ранее добавленный прослушиватель изменений предпочтительного для стратегии аудиоустройства.

Сообщить о возможностях устройства

В рамках реализации Audio HAL поставщики реализуют API, которые поддерживают возможности устройств создания отчетов. В этом разделе объясняются типы данных и методы, используемые для сообщения о возможностях устройства, и перечисляются некоторые изменения, внесенные в аудио HIDL HAL V7 для поддержки нескольких устройств.

Типы данных

В аудио HIDL HAL V7 о возможностях устройства сообщается с помощью структур AudioProfile и AudioTransport . Структура AudioTransport описывает возможности аудиопорта с AudioProfile для известных аудиоформатов или с необработанными аппаратными дескрипторами для форматов, которые не известны платформе. Структура AudioProfile содержит аудиоформат, частоты дискретизации, поддерживаемые профилем, и список масок каналов, как показано в следующем блоке кода из types.hal :

/**
* Configurations supported for a certain audio format.
*/
struct AudioProfile {
   AudioFormat format;
   /** List of the sample rates (in Hz) supported by the profile. */
   vec<uint32_t> sampleRates;
   /** List of channel masks supported by the profile. */
   vec<AudioChannelMask> channelMasks;
};

В аудио HIDL HAL V7 тип данных AudioPort определяется структурами AudioTransport и AudioProfile для описания возможностей устройства.

Примечание. До версии Android 12 структура SDK API AudioDeviceInfo описывает возможности звука, такие как частоты дискретизации, форматы и маски каналов, в формате плоского массива, в котором отсутствует четкая взаимосвязь между форматом, частотой дискретизации и масками каналов. AudioProfile , как определено выше, заменил его в Android 12.

Аудио-методы HAL

Диспетчер политики аудио использует следующие методы для запроса возможностей устройства:

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

Следующий код из IDevice.hal показывает интерфейс метода getAudioPort :

   /**
    * Returns the list of supported attributes for a given audio port.
    *
    * As input, 'port' contains the information (type, role, address etc...)
    * needed by the HAL to identify the port.
    *
    * As output, 'resultPort' contains possible attributes (sampling rates,
    * formats, channel masks, gain controllers...) for this port.
    *
    * @param port port identifier.
    * @return retval operation completion status.
    * @return resultPort port descriptor with all parameters filled up.
    */
   getAudioPort(AudioPort port)
           generates (Result retval, AudioPort resultPort);

Изменения в устаревшем API

Для поддержки нескольких профилей аудио в версии 3.2 устаревшего API добавлена ​​новая структура под названием audio_port_v7 . Более подробную информацию смотрите в исходном коде .

Из-за добавления audio_port_v7 в версию 3.2 устаревшего API добавлен новый API под названием get_audio_port_v7 для запроса возможностей устройств с использованием структуры audio_port_v7 .

Следующий код из audio.h показывает определение API get_audio_port_v7 :

/**
 * Fills the list of supported attributes for a given audio port.
 * As input, "port" contains the information (type, role, address etc...)
 * needed by the HAL to identify the port.
 * As output, "port" contains possible attributes (sampling rates,
 * formats, channel masks, gain controllers...) for this port. The
 * possible attributes are saved as audio profiles, which contains audio
 * format and the supported sampling rates and channel masks.
 */
 int (*get_audio_port_v7)(struct audio_hw_device *dev,
                          struct audio_port_v7 *port);

Примечание. getAudioPort вызывает API get_audio_port_v7 только в том случае, если версия аудио HIDL HAL равна 7 или новее, а устаревшая версия API — 3.2 или новее. Для аудио HIDL HAL версий 6 и ниже или устаревших версий API ниже 3.2 getAudioPort вместо этого вызывает API get_audio_port для запроса возможностей устройства.

Данные из устаревшего API get_audio_port должны быть заполнены в новый формат AudioPort , если устаревшая версия API ниже 3.2, а версия HIDL HAL — 7 или выше. В этом случае предполагается, что все сообщаемые частоты дискретизации и маски каналов из get_audio_port поддерживаются для всех возвращаемых форматов, что обеспечивает прямое сопоставление значений get_audio_port с новой структурой AudioPort .

Пример реализации API

В этом разделе описываются несколько наборов тестов, содержащих методы, использующие API, описанные в предыдущих разделах. Обратитесь к этим методам для получения некоторых примеров реализации и использования этих API.

Пример использования системных API setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy и OnPreferredDevicesForStrategyChangedListener находится в методе PreferredDeviceRoutingTest , который находится в GTS.

Чтобы увидеть пример новой структуры в AudioDeviceInfo , см. метод AudioManagerTest#testGetDevices который находится в CTS.

Примечание. Код CTS для этой реализации будет опубликован в выпуске Android 12.

Пример реализации get_audio_port_v7 находится в audio_hal.c и показывает, как запрашиваются возможности для нескольких устройств.

Валидация

В этом разделе представлена ​​информация о проверке Audio Manager с помощью CTS и GTS (Google Mobile Services Test Suite).

Примечание. GTS имеет закрытый исходный код и имеет более полные тесты для API предпочтительных устройств, чем CTS. Для дополнительного тестового покрытия также запустите тесты CTS.

CTS-тесты

Тесты CTS расположены в android.media.cts.AudioManagerTest .

Ниже приведен список доступных тестов Audio Manager:

• AudioManagerTest#testGetDevices

  Проверяет точные возможности аудиоустройства. Он также проверяет, что возвращенные аудиопрофили в структуре AudioDeviceInfo сохраняют содержимое старого формата плоского массива, но находятся в новом формате AudioProfile .

  Примечание. Возвращаемый массив AudioProfile из вызова AudioDeviceInfo#getAudioProfiles() должен содержать то же содержимое, что и сглаженные массивы из вызовов AudioDeviceInfo#getEncodings() , AudioDeviceInfo#getSampleRates() и AudioDeviceInfo#getChannelMasks() .

• AudioManagerTest#testPreferredDevicesForStrategy и AudioManagerTest#testPreferredDeviceForCapturePreset

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

ГТС-тесты

Тесты GTS расположены в com.google.android.gts.audioservice.AudioServiceHostTest .

Чтобы проверить правильность работы API для предпочтительных устройств для стратегии и предустановок захвата, запустите тесты AudioServiceHostTest#testPreferredDeviceRouting и AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset .