Roteamento de dispositivo de áudio combinado

O recurso de roteamento combinado de dispositivos de áudio adiciona suporte para streaming de áudio para vários dispositivos de áudio simultaneamente. Usando esse recurso, aplicativos privilegiados podem selecionar vários dispositivos preferenciais para uma estratégia específica por meio de APIs do sistema. Os aplicativos podem descobrir recursos de dispositivos de áudio com mais precisão usando as APIs públicas fornecidas por esse recurso. Para versões 11 e anteriores do Android, a implementação da estrutura 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 determinado caso de uso.

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. O roteamento para vários dispositivos USB simultaneamente não é suportado.

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

Esta página aborda como implementar suporte para streaming de áudio para vários dispositivos de áudio e como validar a implementação desse recurso.

Nota: A implementação deste recurso é puramente em AOSP. Alguns dos testes estão localizados no GTS, que não está no AOSP.

Suporta streaming de áudio para vários dispositivos de áudio

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

• As APIs do sistema lidam com vários dispositivos preferenciais para uma estratégia.
• A interface HIDL, implementada pelo fornecedor como parte do HAL de áudio, relata os recursos do dispositivo.

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

Lide com vários dispositivos preferenciais para uma estratégia

O Audio Policy Manager oferece APIs de sistema para oferecer melhor suporte ao streaming de áudio para vários dispositivos de áudio simultaneamente. Essas APIs de sistema permitem configurar, obter e remover vários dispositivos preferenciais para uma determinada estratégia. Até o Android 12, esse recurso era compatível apenas com um único dispositivo.

O Audio Policy Manager introduz o conceito de dispositivos de mídia ativos para descrever os dispositivos com maior probabilidade de serem escolhidos para reprodução de mídia. Quando um dispositivo destacável é conectado, os fluxos de saída de áudio HAL que podem ser roteados para esse dispositivo podem ter que ser abertos e testados em busca de atributos suportados.

Nota: Se houver suporte para um perfil de áudio dinâmico e nem todas as trilhas ativas forem redirecionadas, o fluxo de saída não será reaberto imediatamente quando o dispositivo for conectado, mas algum tempo depois, quando todas as trilhas estiverem inativas.

Um dispositivo de áudio deve ser especificado ao abrir um fluxo de saída. O dispositivo de mídia ativo é o dispositivo usado quando fluxos de saída são abertos neste contexto.

A seleção do dispositivo de mídia ativo pode mudar dependendo dos dispositivos reais 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 preferenciais para mídia estiverem disponíveis, todos serão escolhidos como dispositivos ativos.
2. Caso contrário, será escolhido o último dispositivo removível conectado.
3. Se não houver dispositivos removíveis conectados, as regras de política de áudio padrão para escolha de dispositivos de saída serão aplicadas para escolher dispositivos ativos.

Um fluxo de saída deve satisfazer os seguintes critérios para ser reaberto e roteado para os dispositivos ativos para que a melhor configuração seja escolhida para a reprodução:

• O fluxo de saída deve suportar os dispositivos ativos.
• O fluxo de saída deve suportar perfis dinâmicos.
• O fluxo de saída não deve estar atualmente roteado para dispositivos ativos.

Para aplicar uma nova seleção de dispositivo, o Audio Policy Manager fecha e reabre um fluxo de saída após a conexão do dispositivo se o fluxo de saída estiver ocioso ou adia-o para quando o fluxo 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 preferencial para roteamento de áudio para uma determinada estratégia. Observe que o dispositivo pode não estar disponível no momento em que o dispositivo preferencial é definido, mas será usado quando estiver disponível.

• removePreferredDeviceForStrategy

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

• getPreferredDeviceForStrategy

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

• setPreferredDevicesForStrategy

  Define os dispositivos preferenciais para uma determinada estratégia.

• getPreferredDevicesForStrategy

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

• OnPreferredDevicesForStrategyChangedListener

  Define uma interface para notificação de alterações nos dispositivos de áudio preferenciais definidos para uma determinada estratégia de áudio.

• addOnPreferredDevicesForStrategyChangedListener

  Adiciona um ouvinte para ser notificado sobre alterações no dispositivo de áudio preferencial da estratégia.

• removeOnPreferredDevicesForStrategyChangedListener

  Remove um ouvinte adicionado anteriormente de alterações no dispositivo de áudio preferencial da estratégia.

Reportar recursos do dispositivo

Como parte da implementação do Audio HAL, os fornecedores implementam APIs que suportam recursos de dispositivos de relatório. Esta seção explica os tipos de dados e métodos usados ​​para relatar as capacidades do dispositivo e lista algumas alterações feitas no áudio HIDL HAL V7 para suportar vários dispositivos.

Tipos de dados

No áudio HIDL HAL V7, os recursos do dispositivo são relatados 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 que não são conhecidos pela plataforma. A estrutura AudioProfile contém o formato de áudio, as taxas de amostragem suportadas pelo perfil e a lista de máscaras de canal, conforme mostrado no seguinte bloco de código 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;
};

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

Observação: antes do Android 12, a estrutura da API SDK AudioDeviceInfo descreve recursos de áudio, como taxas de amostragem, formatos e máscaras de canal em um formato de matriz achatada, que não possui uma relação clara entre formato, taxas de amostragem e máscaras de canal. AudioProfile , conforme definido acima, o substituiu a partir do Android 12.

Métodos 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 suportados e suas respectivas taxas de amostragem.
• getAudioPort: Retorna a lista de atributos suportados (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 . Veja 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);

Observação: getAudioPort chama a API get_audio_port_v7 somente quando a versão HAL do HIDL de áudio é 7 ou posterior e a versão da API legada é 3.2 ou posterior. Para áudio HIDL HAL versões 6 e anteriores ou versões de API herdadas abaixo de 3.2, getAudioPort chama a API get_audio_port para consultar os recursos do dispositivo.

Os dados da API herdada get_audio_port devem ser preenchidos no novo formato AudioPort quando a versão da API herdada for inferior a 3.2 e a versão HIDL HAL for 7 ou superior. Nesse caso, presume-se que todas as taxas de amostragem e máscaras de canal relatadas de get_audio_port sejam suportadas para todos os formatos retornados, permitindo um mapeamento direto dos valores get_audio_port para a nova estrutura AudioPort .

Exemplos de implementações de API

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

Um exemplo de utilização das APIs do setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy e OnPreferredDevicesForStrategyChangedListener está no método PreferredDeviceRoutingTest , que está 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.

Observação: o código CTS para esta implementação será tornado público com o lançamento do Android 12.

Um exemplo de implementação para get_audio_port_v7 está localizado em audio_hal.c e mostra como os recursos são consultados para vários dispositivos.

Validação

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

Nota: GTS é de código fechado e possui testes mais completos para a API de dispositivos preferenciais do que CTS. Para maior cobertura de teste, execute também os testes CTS.

Testes CTS

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

A seguir está 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 nivelado mais antigo, mas estão no novo formato AudioProfile .

  Nota: A matriz AudioProfile retornada de uma chamada para AudioDeviceInfo#getAudioProfiles() deve conter o mesmo conteúdo que as matrizes niveladas de chamadas para AudioDeviceInfo#getEncodings() , AudioDeviceInfo#getSampleRates() e AudioDeviceInfo#getChannelMasks() .

• AudioManagerTest#testPreferredDevicesForStrategy e AudioManagerTest#testPreferredDeviceForCapturePreset

  Verifique se os dispositivos preferenciais para estratégia e captura de testes de API relacionados à predefinição foram concluídos com êxito.

Testes GTS

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

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