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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Audio Policy Manager предлагает следующий список системных 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

Audio Policy Manager использует следующие методы для запроса возможностей устройства:

  • 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.

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

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

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

Проверка

В этом разделе содержится информация о проверке CTS и GTS (набор тестов Google Mobile Services) для Audio Manager.

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 .