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 nenhum slot extra 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 de dispositivos de áudio.
Para remover o limite do número de tipos de dispositivos de áudio, esses tipos agora são valores enumerados em vez de máscaras de bits.
Todos os tipos de dispositivos de áudio existentes são mantidos como estão. O AUDIO_DEVICE_BIT_IN
ainda é usado para distinguir dispositivos de entrada ou saída. Ao adicionar novos tipos de dispositivo de áudio, eles são
enumerados nos espaços 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 dispositivo de áudio como máscaras de bits.
- Usar o valor
audio_devices_t
para representar vários dispositivos de áudio. - Verificação se o valor
audio_devices_t
contém tipos de dispositivo de áudio de uma categoria especificada.
Para representar vários tipos de dispositivos de áudio, é usada uma classe chamada DeviceTypeSet
no
/libaudiofoundation/include/media/AudioContainers.h
, 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 no código C, é possível usar 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 o caso de 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 dispositivo de áudio
são do mesmo tipo.
Implementação
Os OEMs precisam remover a representação de campo de bit do tipo de dispositivo de áudio da implementação do HAL de áudio.
- Remova todo o armazenamento de dispositivos em um campo de bit.
O
audio_devices_t
não pode ser usado para representar vários tipos de dispositivo de áudio. Em vez disso, use uma lista ou um vetor. - Pare de usar operações de bits para comparações de tipos de dispositivos.
Antes do Android 11, os tipos de dispositivo de áudio podiam ser usados como um bitset. Nesse caso, é comum usar operações de bit para comparações de tipos de dispositivos. Quando novos tipos de dispositivos de áudio enumerados são adicionados, as operações de bit 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 específica, use funções auxiliares em
/system/media/audio/include/system/audio.h
. Por exemplo,audio_is_output_device(audio_devices_t device)
. - 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
, emsystem/media/audio/include/system/audio-base-utils.h
. Todos esses valores são reservados, mas podem ser descontinuados, porque não serão corretos quando novos tipos de dispositivo de áudio enumerados forem adicionados. Há novos grupos de tipos de dispositivos de áudio definidos emaudio-base-utils.h
, que são matrizes de tipos de dispositivos de áudio, comoAUDIO_DEVICE_OUT_ALL_ARRAY
. - Implemente os métodos
create_audio_patch()
erelease_audio_patch()
para roteamento em vez deset_parameters
.O método
set_parameters
usa tipos de dispositivo de áudio como um bitset. Portanto, podem ocorrer resultados inesperados se novos tipos de dispositivo de áudio enumerados forem adicionados.Atualmente, dois tipos de patches de áudio são necessários:
- Misturar para patches de dispositivo, para reprodução
- Dispositivo para misturar patches, para gravação
Em atualizações subsequentes, talvez sejam necessários outros patches para dispositivos.
Ao criar um patch de áudio, se o handle de patch não for especificado, o HAL de áudio será necessário para gerar um handle de patch exclusivo que possa identificar o patch de áudio. Caso contrário, o HAL de áudio precisa usar o identificador de patch de áudio fornecido para atualizar o patch de áudio.
Se você estiver usando uma HAL de áudio legada e o wrapper HIDL do AOSP, a HAL de áudio legada vai definir a versão principal da HAL como 3.0.
Para ativar o recurso de patch de áudio, o HAL de áudio precisa definir a versão principal do HAL como 3.0 ou mais recente. Consulte
Device::supportsAudioPatches()
na implementação padrão de HIDL 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 ou reverter a refatoração do dispositivo de áudio no framework que permite adicionar tipos de dispositivos de áudio.
Todos os tipos de dispositivo de áudio adicionados permitem representar um tipo de dispositivo com um único bit definido, para que as implementações atuais da HAL ainda funcionem.
Se novos tipos de dispositivo de áudio forem adicionados e os OEMs quiserem usá-los, eles
precisam 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 stream pode causar resultados inesperados quando
novos tipos de dispositivo de áudio são adicionados.
Validação
O trabalho necessário para OEMs é atualizar as implementações do 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.