Limite de tipo de dispositivo

No áudio do Android, audio_devices_t é usado para representar o tipo de dispositivo de áudio. Ele é amplamente usado no código-fonte de áudio como um campo de bits para filtrar ou selecionar um ou mais dispositivos especificados. Antes do Android 11, havia um limite de 30 tipos de dispositivos de entrada/saída de áudio, e não havia slots extras para adicionar novos tipos de dispositivos de áudio. Removemos o limite do número de tipos de dispositivos de áudio para permitir a adição de novos tipos.

Para remover o limite do número de tipos de dispositivos de áudio, eles agora são valores enumerados em vez de máscaras de bits.

Todos os tipos de dispositivos de áudio atuais são mantidos como estão. AUDIO_DEVICE_BIT_IN ainda é usado para distinguir dispositivos de entrada ou saída. Ao adicionar novos tipos de dispositivos de áudio, eles são valores enumerados nas lacunas entre os valores atuais.

Os OEMs não devem usar audio_devices_t como uma máscara de bits, porque isso pode causar resultados inesperados quando novos tipos de dispositivos de áudio enumerados são adicionados.

Exemplos e origem

Antes do Android 11, havia dois usos típicos de tipos de dispositivos de áudio como máscaras de bits.

  • Usando o valor audio_devices_t para representar vários dispositivos de áudio.
  • Verificar se o valor audio_devices_t contém tipos de dispositivos de áudio de uma categoria especificada.

Para representar vários tipos de dispositivos de áudio, uma classe chamada DeviceTypeSet no /libaudiofoundation/include/media/AudioContainers.h é usada, que é um contêiner std::set de audio_devices_t. A classe é declarada na biblioteca libaudiofoundation disponível para o fornecedor. Para representar vários tipos de dispositivos de áudio em código C, use uma matriz ou uma lista de audio_devices_t.

Para verificar se um único tipo de dispositivo é de uma categoria especificada, use as funções auxiliares audio_is_.*_device em /system/media/audio/include/system/audio.h. Para vários tipos de dispositivos de áudio, use funções auxiliares em libaudiofoundation. Por exemplo, use areAllOfSameDeviceType (DeviceTypeSet, std::function) em AudioContainers.h para verificar se todos os tipos de dispositivos de áudio fornecidos são do mesmo tipo.

Implementação

Os OEMs precisam remover a representação de campo de bits do tipo de dispositivo de áudio da implementação da HAL de áudio.

  1. Remova todo o armazenamento de dispositivos em um campo de bits.

    O audio_devices_t não pode ser usado para representar vários tipos de dispositivos de áudio. Em vez disso, use uma lista ou um vetor.

  2. Pare de usar operações de bits para comparações de tipos de dispositivos.

    Antes do Android 11, os tipos de dispositivos de áudio podiam ser usados como um campo de bits. Nesse caso, é comum usar operações de bits para comparações de tipos de dispositivos. Quando novos tipos de dispositivos de áudio enumerados são adicionados, as operações de bits podem causar resultados inesperados. Em vez disso, use funções auxiliares como alternativa. Se houver um único tipo de dispositivo de áudio, use a comparação direta para comparar os dois valores. Para verificar se um tipo de dispositivo de áudio é de uma categoria especificada, use funções auxiliares em /system/media/audio/include/system/audio.h. Por exemplo, audio_is_output_device(audio_devices_t device).

  3. Pare de usar valores predefinidos para grupos de tipos de dispositivos de áudio.

    Há alguns valores predefinidos para grupos de tipos de dispositivos de áudio, AUDIO_DEVICE_OUT_ALL, em system/media/audio/include/system/audio-base-utils.h. Todos esses valores são reservados, mas podem ficar obsoletos porque não estarão corretos quando novos tipos de dispositivos de áudio enumerados forem adicionados. Há novos grupos de tipos de dispositivos de áudio definidos em audio-base-utils.h, que são matrizes de tipos de dispositivos de áudio, como AUDIO_DEVICE_OUT_ALL_ARRAY.

  4. Implemente os métodos create_audio_patch() e release_audio_patch() para roteamento em vez de set_parameters.

    O método set_parameters usa tipos de dispositivos de áudio como um campo de bits. Portanto, pode haver resultados inesperados se novos tipos de dispositivos de áudio enumerados forem adicionados.

    No momento, são necessários dois tipos de patches de áudio:

    • Mixar para patches de dispositivo, para reprodução
    • Dispositivo para mixar patches, para gravação

    Em atualizações subsequentes, talvez sejam necessários outros patches para cada dispositivo.

    Ao criar um patch de áudio, se o identificador não for especificado, a HAL de áudio precisará gerar um identificador exclusivo que possa identificar o patch de áudio. Caso contrário, o HAL de áudio vai usar o identificador de patch de áudio fornecido para atualizar o patch.

    Se você estiver usando uma HAL de áudio legada e o wrapper HIDL do AOSP, a HAL de áudio legada precisará definir a versão principal da HAL como 3.0.

    Para ativar o recurso de patch de áudio, a HAL de áudio precisa definir a versão principal da HAL como 3.0 ou mais recente. Consulte Device::supportsAudioPatches() na implementação HIDL padrão para mais informações, que também podem ser encontradas na HAL de áudio para Cuttlefish.

Personalização

Não é possível desativar o recurso nem reverter a refatoração do dispositivo de áudio no framework que permite adicionar tipos de dispositivos de áudio.

Todos os tipos de dispositivos de áudio adicionados permitem representar um tipo de dispositivo com um único bit definido. Assim, as implementações atuais da HAL ainda funcionam.

Se novos tipos de dispositivos de áudio forem adicionados e os OEMs quiserem usá-los, eles precisarão fazer upgrade da implementação da HAL de áudio e mudar para a versão 6.0 ou mais recente do HIDL. É obrigatório fazer upgrade da versão principal da HAL para 3.0 e implementar os métodos create_audio_patch e release_audio_patch, porque usar set_parameters para rotear o fluxo pode causar resultados inesperados quando novos tipos de dispositivos de áudio são adicionados.

Validação

O trabalho necessário para os OEMs é atualizar as implementações de HAL. O VTS para HAL de áudio pode ser usado para validar se a implementação funciona conforme o esperado. Todos os testes podem ser encontrados nos arquivos VTS.