O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Encaminhamento de dispositivo de áudio combinado

O recurso de roteamento de dispositivo de áudio combinado adiciona suporte para streaming de áudio para vários dispositivos de áudio simultaneamente. Usando esse recurso, os aplicativos com privilégios podem selecionar vários dispositivos preferenciais para um determinado estratégia 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 este recurso. Para as 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, 2 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 BLE ou o uso de várias placas de som 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.

Compatível com 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.

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

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

O Policy Manager Áudio introduz o conceito de dispositivos de mídia ativos para descrever os dispositivos que são mais susceptíveis de serem escolhidos para reprodução de mídia. Quando um dispositivo removível é conectado, os fluxos de saída de áudio HAL que podem ser roteados para este dispositivo podem ter que ser abertos e sondados para os atributos suportados.

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

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

  1. Se todos os dispositivos preferenciais para mídia estiverem disponíveis, todos eles serão escolhidos como dispositivos ativos.
  2. Caso contrário, o último dispositivo removível conectado é 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 sã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 oferecer suporte a perfis dinâmicos.
  • O fluxo de saída não deve ser 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 na conexão do dispositivo se o fluxo de saída estiver ocioso ou o adia para quando o fluxo de saída é colocado em espera.

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

  • setPreferredDeviceForStrategy

    Define o dispositivo preferido para o 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 é usado assim que é disponibilizado.

  • removePreferredDeviceForStrategy

    Remove o dispositivo de áudio preferido (s) anteriormente definida com setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy .

  • getPreferredDeviceForStrategy

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

  • setPreferredDevicesForStrategy

    Define os dispositivos preferenciais para uma determinada estratégia.

  • getPreferredDevicesForStrategy

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

  • OnPreferredDevicesForStrategyChangedListener

    Define uma interface para notificação de mudanças nos dispositivos de áudio preferenciais que são configurados para uma determinada estratégia de áudio.

  • addOnPreferredDevicesForStrategyChangedListener

    Adiciona um ouvinte para ser notificado sobre mudanças no dispositivo de áudio preferido pela estratégia.

  • removeOnPreferredDevicesForStrategyChangedListener

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

Recursos do dispositivo de relatório

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

Tipos de dados

Em HIDL áudio HAL V7, as capacidades do dispositivo são reportados utilizando os AudioProfile e AudioTransport estruturas. O AudioTransport estrutura 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. O AudioProfile estrutura contém o formato de áudio, as taxas de amostragem suportados pelo perfil, e a lista de máscaras de canais, como mostrado no bloco de código que se segue a partir 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;
};

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

Métodos de áudio HAL

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 canais, controladores de ganho) para uma determinada porta de áudio.

O seguinte código de IDevice.hal mostra a interface para o getAudioPort método:

   /**
    * 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 suportar vários perfis de áudio, a versão 3.2 da API legado acrescenta uma nova estrutura chamada audio_port_v7 . Ver o código-fonte para mais detalhes.

Por causa da adição de audio_port_v7 , versão 3.2 da API legado adiciona uma nova API chamada get_audio_port_v7 para recursos de consulta dos dispositivos usando o audio_port_v7 estrutura.

O seguinte código de audio.h mostra a definição do get_audio_port_v7 API:

/**
 * 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);

Dados do legado get_audio_port API tem de ser preenchido para o novo AudioPort formato quando a versão legado API é inferior a 3.2 ea versão HIDL HAL é 7 ou acima. Neste caso, todas as taxas de amostragem e máscaras de canais de relatado get_audio_port são assumidos para serem suportados por todos os formatos de retorno, permitindo um mapeamento simples de get_audio_port valores para o novo AudioPort estrutura.

Implementações de API de exemplo

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 da utilização dos setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy e OnPreferredDevicesForStrategyChangedListener APIs do sistema é no PreferredDeviceRoutingTest método, que está localizado em GTS.

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

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

Validação

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

Testes CTS

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

A seguir está a lista de testes do Gerenciador de áudio disponíveis:

  • AudioManagerTest#testGetDevices

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

  • 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

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

Para validar se as APIs para dispositivos preferidos para estratégia e captura de trabalho pré-definido corretamente, execute o AudioServiceHostTest#testPreferredDeviceRouting e AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset testes.