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

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

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

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

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

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

В 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 для описания возможностей устройства.

Аудио-методы 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);

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

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

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

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

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

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

Проверка

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

CTS-тесты

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

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

  • AudioManagerTest#testGetDevices

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

  • AudioManagerTest#testPreferredDevicesForStrategy и AudioManagerTest#testPreferredDeviceForCapturePreset

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

ГТС-тесты

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

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