No áudio do Android, audio_devices_t
é usado para representar o tipo de dispositivo de áudio. Está
amplamente utilizado no código-fonte de áudio como um campo de bit para filtrar ou selecionar um ou mais
específicos. Antes do Android 11, havia um limite de 30
dispositivos de entrada/saída de áudio e nenhum slot extra para adicionar novos tipos de dispositivo de áudio. Nós
removeu o limite para o número de tipos de dispositivos de áudio permitidos
novos tipos de dispositivos de áudio a serem adicionados.
Para remover o limite de tipos de dispositivos de áudio, agora os tipos de dispositivos de áudio foram valores enumerados em vez de bitmasks.
Todos os tipos de dispositivos de áudio existentes são mantidos como estão. AUDIO_DEVICE_BIT_IN
é
usado para distinguir dispositivos de entrada ou saída. Ao adicionar novos tipos de dispositivos de áudio,
valores enumerados nas lacunas entre os valores existentes.
OEMs não devem usar audio_devices_t
como bitmask, 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 dispositivos de áudio como bitmask.
- Uso do valor
audio_devices_t
para representar vários dispositivos de áudio. - Como verificar se o valor
audio_devices_t
contém tipos de dispositivos de áudio de uma categoria específica.
Para representar vários tipos de dispositivos de áudio, uma classe chamada DeviceTypeSet
no
/libaudiofoundation/include/media/AudioContainers.h
é usado, que é um contêiner std::set
de audio_devices_t
. O
é declarado no arquivo HTTP
libaudiofoundation
. Para representar
vários áudios
tipos de dispositivo em código C, uma matriz ou lista de audio_devices_t
pode ser usada.
Para verificar se um único tipo de dispositivo pertence à categoria especificada, use as funções auxiliares
audio_is_.*_device
em
/system/media/audio/include/system/audio.h
.
Para casos de vários tipos de dispositivos de áudio, use as funções auxiliares em libaudiofoundation
. Para
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 do campo de bits do tipo de dispositivo de áudio da implementação da HAL de áudio.
- Remove todo o armazenamento de dispositivos em um campo bit.
audio_devices_t
não pode ser usado para representar vários dispositivos de áudio tipos 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 dispositivos de áudio podiam ser usados como bitfield. Nesse caso, é comum usar operações bit para tipos de dispositivos e comparações. Quando novos tipos de dispositivos de áudio enumerados são adicionados, as operações de bit podem causar resultados inesperados. Em vez disso, use as funções auxiliares como alternativa. Se houver um único tipo de dispositivo de áudio e, em seguida, usar a comparação direta para comparar os dois valores. Para verificar se há um áudio o tipo de dispositivo pertence a uma categoria especificada, use funções auxiliares na
/system/media/audio/include/system/audio.h
. Por exemplo,audio_is_output_device(audio_devices_t device)
. - Parar de usar valores predefinidos para grupos de tipos de dispositivos de áudio.
Existem 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 reservados, mas podem ser descontinuados, porque não estarão corretos quando novos endereços enumerados dispositivos de áudio sejam adicionados. Há novos grupos de tipos de dispositivos de áudio definidos noaudio-base-utils.h
, que são matrizes de tipos de dispositivos de áudio, como:AUDIO_DEVICE_OUT_ALL_ARRAY
. - Implementar
create_audio_patch()
erelease_audio_patch()
métodos para roteamento em vez deset_parameters
.O método
set_parameters
usa tipos de dispositivos de áudio como um bitfield. Assim, pode haver resultados inesperados se novos tipos de dispositivos de áudio enumerados forem adicionados.Atualmente, são necessários dois tipos de patches de áudio:
- Mix para patches do dispositivo, para reprodução
- Dispositivo para misturar patches, para gravação
Nas atualizações subsequentes, podem ser necessários patches adicionais para cada dispositivo.
Ao criar um patch de áudio, se o identificador de patch não estiver especificada, a HAL de áudio é necessária para gerar um identificador de patch exclusivo que possa identificar o patch de áudio. Caso contrário, a HAL de áudio deve 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 precisará definir a versão principal da HAL para a versão 3.0.
Para ativar o recurso de patch de áudio, a HAL de áudio deve definir a versão principal da HAL para 3.0 ou mais alto. Consulte
Device::supportsAudioPatches()
em 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 nem reverter a refatoração do dispositivo de áudio no que possibilita adicionar tipos de dispositivos de áudio.
Todos os tipos de dispositivos de áudio adicionados permitem representar um tipo de dispositivo com um único conjunto de bits, então as implementações atuais da HAL ainda funcionam.
Se novos tipos de dispositivos de áudio forem adicionados e os OEMs quiserem usá-los,
precisam atualizar a implementação da HAL de áudio e migrar para a versão 6.0 ou superior do HIDL. Está
é obrigatório fazer o upgrade da versão principal da HAL para a 3.0 e implementar a
métodos create_audio_patch
e release_audio_patch
, porque
o uso de set_parameters
para rotear o stream pode causar resultados inesperados ao
novos tipos de dispositivos de áudio são adicionados.
Validação
O trabalho necessário para OEMs é atualizar as implementações da HAL. VTS para a HAL de áudio pode ser usada para validar se a implementação funciona conforme o esperado. Tudo os testes podem ser encontrados Arquivos VTS.