Roteamento combinado para dispositivos de áudio

O recurso de roteamento combinado de dispositivo de áudio adiciona suporte a streaming de áudio para vários dispositivos de áudio simultaneamente. Com esse recurso, os apps com privilégios podem selecionar vários dispositivos preferidos para uma estratégia específica usando APIs do sistema. Os apps podem descobrir funções de dispositivos de áudio com mais precisão usando as APIs públicas fornecidas por esse recurso. Nas versões do Android 11 e anteriores, a implementação do framework de áudio tem suporte limitado para vários dispositivos de áudio do mesmo tipo (por exemplo, dois fones de ouvido Bluetooth A2DP) conectados simultaneamente. As regras de roteamento de áudio padrão também não permitem que os usuários selecionem vários dispositivos do mesmo tipo para um caso de uso específico.

A partir do Android 12, essas limitações foram removidas para permitir novos casos de uso, como transmissão de áudio, multicast para um grupo de fones de ouvido de áudio BLE ou seleção de várias placas de som USB simultaneamente. Não é possível rotear para vários dispositivos USB ao mesmo tempo.

A partir do Android 14, o framework USB oferece suporte ao roteamento para vários dispositivos USB, desde que eles sejam de tipos diferentes de dispositivos de áudio e haja suporte do kernel e do fornecedor para conectar vários dispositivos USB simultaneamente.

Nesta página, explicamos como implementar o suporte para streaming de áudio em vários dispositivos de áudio e como validar a implementação desse recurso.

Suporte para streaming de áudio em vários dispositivos de áudio

Há dois conjuntos de APIs no Android 12 que oferecem suporte a esse recurso:

  • As APIs do sistema processam vários dispositivos preferidos para uma estratégia.
  • A interface HIDL, implementada pelo fornecedor como parte do HAL de áudio, informa as funcionalidades do dispositivo.

As seções a seguir discutem cada uma dessas APIs em mais detalhes.

Processar vários dispositivos preferidos para uma estratégia

O Audio Policy Manager oferece APIs do sistema para melhorar a compatibilidade com streaming de áudio para vários dispositivos de áudio simultaneamente. Essas APIs do sistema permitem definir, receber e remover vários dispositivos preferidos para uma determinada estratégia. Até o Android 12, esse recurso era compatível apenas com um dispositivo.

O Audio Policy Manager apresenta o conceito de dispositivos de mídia ativos para descrever os dispositivos que provavelmente serão escolhidos para reprodução de mídia. Quando um dispositivo removível é conectado, os fluxos de saída do HAL de áudio que podem ser encaminhados para esse dispositivo precisam ser abertos e testados para atributos compatíveis.

É necessário especificar um dispositivo de áudio ao abrir um stream de saída. O dispositivo de mídia ativo é aquele usado quando fluxos de saída são abertos nesse contexto.

A seleção de dispositivos de mídia ativos pode mudar dependendo dos dispositivos conectados ou desconectados. O Audio Policy Manager usa a seguinte série de regras para escolher dispositivos de mídia ativos:

  1. Se todos os dispositivos preferidos para mídia estiverem disponíveis, eles serão escolhidos como dispositivos ativos.
  2. Caso contrário, o último dispositivo removível conectado será escolhido.
  3. Se não houver dispositivos removíveis conectados, as regras de política de áudio padrão para escolher dispositivos de saída serão aplicadas para escolher dispositivos ativos.

Um fluxo de saída precisa atender aos seguintes critérios para ser reaberto e encaminhado aos dispositivos ativos para que a melhor configuração seja escolhida para a reprodução:

  • O fluxo de saída precisa ser compatível com os dispositivos ativos.
  • O fluxo de saída precisa ser compatível com perfis dinâmicos.
  • O fluxo de saída não pode estar roteado para dispositivos ativos.

Para aplicar uma nova seleção de dispositivo, o Audio Policy Manager fecha e reabre um stream de saída quando um dispositivo é conectado se o stream de saída estiver inativo ou adiado para quando o stream de saída for colocado em espera.

O Audio Policy Manager oferece a seguinte lista de APIs do sistema(conforme definido em AudioManager.java):

  • setPreferredDeviceForStrategy

    Define o dispositivo preferido para o roteamento de áudio de uma determinada estratégia. O dispositivo pode não estar disponível no momento em que o preferido é definido, mas será usado assim que estiver disponível.

  • removePreferredDeviceForStrategy

    Remove os dispositivos de áudio preferenciais definidos anteriormente com setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy.

  • getPreferredDeviceForStrategy

    Retorna o dispositivo preferido para uma estratégia de áudio definida anteriormente com setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy.

  • setPreferredDevicesForStrategy

    Define os dispositivos preferidos para uma determinada estratégia.

  • getPreferredDevicesForStrategy

    Retorna os dispositivos preferidos para uma estratégia de áudio definida anteriormente com setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy.

  • OnPreferredDevicesForStrategyChangedListener

    Define uma interface para notificação de mudanças nos dispositivos de áudio preferidos definidos para uma determinada estratégia de áudio.

  • addOnPreferredDevicesForStrategyChangedListener

    Adiciona um listener para receber notificações sobre mudanças no dispositivo de áudio preferido da estratégia.

  • removeOnPreferredDevicesForStrategyChangedListener

    Remove um listener adicionado anteriormente de mudanças no dispositivo de áudio preferido pela estratégia.

Informar recursos do dispositivo

Como parte da implementação da HAL de áudio, os fornecedores implementam as APIs que oferecem suporte para informar os recursos do dispositivo. Esta seção explica os tipos de dados e métodos usados para informar as funcionalidades do dispositivo e lista algumas mudanças feitas no HIDL HAL de áudio V7 para oferecer suporte a vários dispositivos.

Tipos de dados

Na HAL HIDL de áudio V7, os recursos do dispositivo são informados usando as estruturas AudioProfile e AudioTransport. A estrutura AudioTransport descreve a capacidade de uma porta de áudio com AudioProfile para formatos de áudio conhecidos ou com descritores de hardware brutos para formatos desconhecidos da plataforma. A estrutura AudioProfile contém o formato de áudio, as taxas de amostragem compatíveis com o perfil e a lista de máscaras de canal, conforme mostrado no bloco de código a seguir de 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;
};

Na HAL HIDL de áudio V7, o tipo de dados AudioPort é definido com as estruturas AudioTransport e AudioProfile para descrever os recursos do dispositivo.

Métodos da HAL de áudio

O Audio Policy Manager usa os seguintes métodos para consultar os recursos do dispositivo:

  • getParameters:Um método genérico para recuperar valores de parâmetros específicos do fornecedor, como formatos de áudio compatíveis e taxas de amostragem correspondentes.
  • getAudioPort:Retorna a lista de atributos compatíveis (como taxas de amostragem, formatos, máscaras de canal, controladores de ganho) para uma determinada porta de áudio.

O código a seguir de IDevice.hal mostra a interface do método 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);

Mudanças na API legada

Para oferecer suporte a vários perfis de áudio, a versão 3.2 da API legada adiciona uma nova estrutura chamada audio_port_v7. Confira o código-fonte para mais detalhes.

Devido à adição de audio_port_v7, a versão 3.2 da API legada adiciona uma nova API chamada get_audio_port_v7 para consultar os recursos dos dispositivos usando a estrutura audio_port_v7.

O código a seguir de audio.h mostra a definição da 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);

Os dados da API get_audio_port legada precisam ser preenchidos no novo formato AudioPort quando a versão da API legada é anterior a 3.2 e a versão do HIDL HAL é 7 ou mais recente. Nesse caso, todas as taxas de amostragem e máscaras de canal informadas de get_audio_port são consideradas compatíveis com todos os formatos retornados, permitindo um mapeamento direto dos valores de get_audio_port para a nova estrutura AudioPort.

Exemplos de implementações da API

Esta seção descreve vários conjuntos de testes que contêm métodos que usam as APIs abordadas nas seções anteriores. Consulte esses métodos para ver alguns exemplos de como essas APIs são implementadas e usadas.

Um exemplo do uso das APIs de sistema setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy e OnPreferredDevicesForStrategyChangedListener está no método PreferredDeviceRoutingTest, localizado no GTS.

Para ver um exemplo da nova estrutura em AudioDeviceInfo em uso, consulte o método AudioManagerTest#testGetDevices, que está localizado no CTS.

Um exemplo da implementação para get_audio_port_v7 está localizado em audio_hal.c e mostra como as funcionalidades são consultadas para vários dispositivos.

Validação

Esta seção fornece informações sobre a validação do Audio Manager pelo CTS e pelo GTS (Google Mobile Services Test Suite).

Testes do CTS

Os testes do CTS estão localizados em android.media.cts.AudioManagerTest.

Confira a seguir a lista de testes disponíveis do Audio Manager:

  • AudioManagerTest#testGetDevices

    Verifica os recursos precisos do dispositivo de áudio. Ele também verifica se os perfis de áudio retornados na estrutura AudioDeviceInfo preservam o conteúdo do formato de matriz achatada mais antigo, mas estão no novo formato AudioProfile.

  • AudioManagerTest#testPreferredDevicesForStrategy e AudioManagerTest#testPreferredDeviceForCapturePreset

    Verifique se os dispositivos preferenciais para testes de API relacionados à estratégia e à captura predefinida foram concluídos com sucesso.

Testes do GTS

Os testes do GTS estão localizados em com.google.android.gts.audioservice.AudioServiceHostTest.

Para validar se as APIs de dispositivos preferidos para estratégia e predefinição de captura funcionam corretamente, execute os testes AudioServiceHostTest#testPreferredDeviceRouting e AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.