Áudio automotivo

O Android Automotive OS (AAOS) se baseia na pilha de áudio principal do Android para oferecer suporte aos casos de uso para operar como o sistema de infoentretenimento em um veículo. O AAOS é responsável pelos sons de infoentretenimento (ou seja, mídia, navegação e mas não é diretamente responsável por toques e avisos que tenham requisitos rigorosos de disponibilidade e tempo. O AAOS fornece sinais e mecanismos para ajudar o veículo a gerenciar o áudio. Afinal, cabe ao veículo decidir quais sons devem ser tocados para o motorista e passageiros, garantindo que sons críticos para a segurança e regulatórios sejam devidamente sem interrupções.

Como o Android gerencia a experiência de mídia do veículo, as fontes externas de mídia como o sintonizador de rádio, precisa ser representado por apps, que podem lidar com áudio eventos principais de foco e de mídia na origem.

O Android 11 inclui as seguintes mudanças no áudio relacionado a automóveis suporte:

• Seleção automática da zona de áudio com base no User-ID associado
• Novos usos do sistema para oferecer suporte a sons específicos para automóveis
• Suporte para foco de áudio HAL
• Foco de áudio atrasado para streams não temporários
• Configuração do usuário para controlar a interação entre a navegação e as chamadas

Sons e streams do Android

Os sistemas de áudio automotivos processam os seguintes sons e streams:

Figura 1. Diagrama de arquitetura centrada em stream

O Android gerencia os sons provenientes de apps Android, controlando esses apps e rotear seus sons para dispositivos de saída na HAL com base no tipo som:

• Streams lógicos, conhecidos como fontes no áudio principal. nomenclatura, são marcadas com Atributos de áudio.
• Streams físicos, conhecidos como dispositivos no áudio principal nomenclatura, não têm informações de contexto após a mistura.

Para confiabilidade, sons externos vindos de fontes como toques de aviso do cinto de segurança) são gerenciadas fora do Android, abaixo HAL ou até mesmo em hardware separado. Os implementadores de sistema precisam fornecer um mixer aceita um ou mais streams de entrada de som do Android e combina esses transmite de maneira adequada com as fontes de som externas exigidas pelos veículo

A implementação da HAL e o mixer externo são responsáveis por garantir Sons externos críticos para a segurança são ouvidos e podem ser misturados nas telas e roteá-los para alto-falantes adequados.

Sons do Android

Os aplicativos podem ter um ou mais players que interagem por meio do sistema APIs (por exemplo, AudioManager para o controle de foco ou MediaPlayer para streaming) para emitir um ou mais streams lógicos de dados de áudio. Esses dados poderia ser mono de canal único ou surround 7.1, mas é roteado e tratado como uma única fonte. O fluxo do app está associado a AudioAttributes. que dão ao sistema dicas sobre como o áudio deve ser expresso.

Os streams lógicos são enviados pelo AudioService e roteados para um apenas um dos fluxos de saída física disponíveis, sendo cada um deles a saída de um mixer no AudioFlinger. Depois que os atributos de áudio forem misturados para uma transmissão física, eles não estão mais disponíveis.

Cada stream físico é entregue à HAL de áudio para renderização o hardware. Em apps automotivos, o hardware de renderização pode ser codecs locais (semelhante a dispositivos móveis) ou um processador remoto na rede física em uma rede VPC. De qualquer forma, o trabalho da implementação da HAL de áudio é fornecer dados de amostra reais e torná-los audíveis.

Streams externos

Streams de som que não podem ser roteados pelo Android (para certificação ou por motivos de tempo) podem ser enviadas diretamente ao mixer externo. A partir do Android 11, a HAL agora pode solicitar foco para esses sons externos para informar ao Android para que ele possa realizar as ações apropriadas, como pausar a mídia ou impedir os outros de ganharem o foco.

Se os streams externos forem fontes de mídia que devem interagir com o som ambiente que o Android está gerando (por exemplo, parar a reprodução de MP3 quando um sintonizador externo estiver ativado), esses streams externos devem ser representados por App Android. Esse app pediria seleção de áudio em nome da fonte de mídia em vez da HAL, e responderia às notificações de foco Iniciar/interromper a fonte externa conforme necessário para se encaixar no foco do Android política. O app também é responsável por lidar com eventos de tecla de mídia, como reproduzir/pausar. Um mecanismo sugerido para controlar esses dispositivos externos é o HwAudioSource.

Dispositivo de saída

No nível da HAL de áudio, o tipo de dispositivo AUDIO_DEVICE_OUT_BUS fornece um dispositivo de saída genérico para uso em sistemas de áudio de veículos. O ônibus dispositivo suporta portas endereçáveis (onde cada porta é o ponto final de um stream físico) e deve ser o único tipo de dispositivo de saída compatível um veículo.

Uma implementação do sistema pode usar uma porta de barramento para todos os sons do Android, em Nesse caso, o Android mistura tudo e entrega como um só fluxo. Como alternativa, a HAL pode fornecer uma porta de barramento para cada CarAudioContext entrega simultânea de qualquer tipo de som. Isso possibilita que a HAL implementação para mixar e reduzir os diferentes sons conforme desejado.

A atribuição de contextos de áudio a dispositivos de saída é feita com car_audio_configuration.xml:

Entrada de microfone

Ao capturar áudio, a HAL de áudio recebe uma openInputStream. chamada que inclui um argumento AudioSource indicando como a a entrada de microfone deve ser processada.

A origem de VOICE_RECOGNITION (especificamente o Google Assistente) espera um fluxo de microfone estéreo que tenha um efeito de cancelamento de eco (se disponível), mas nenhum outro processamento é aplicado a ele. O Beamforming é feito pelo Google Assistente.

Entrada de microfone multicanal

Para capturar áudio de um dispositivo com mais de dois canais (estéreo), use um máscara de índice de canais em vez de máscara de índice de posicionamento (como CHANNEL_IN_LEFT). Exemplo:

final AudioFormat audioFormat = new AudioFormat.Builder()
    .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
    .setSampleRate(44100)
    .setChannelIndexMask(0xf /* 4 channels, 0..3 */)
    .build();
final AudioRecord audioRecord = new AudioRecord.Builder()
    .setAudioFormat(audioFormat)
    .build();
audioRecord.setPreferredDevice(someAudioDeviceInfo);

Quando setChannelMask e setChannelIndexMask são definidos, AudioRecord usa apenas o valor definido pelo setChannelMask (máximo de dois canais).

Captura simultânea

No Android 10 e versões mais recentes, o framework do Android oferece suporte à captura simultânea de entradas, mas com restrições para proteger a privacidade do usuário. Como parte dessas restrições, fontes virtuais como AUDIO_SOURCE_FM_TUNER são ignorados e, assim, podem ser são capturados simultaneamente com uma entrada regular (como o microfone). HwAudioSources também não são considerados parte de eventos de captura de tela.

Apps criados para funcionar com dispositivos AUDIO_DEVICE_IN_BUS ou com os dispositivos AUDIO_DEVICE_IN_FM_TUNER secundários precisam depender identificar esses dispositivos e usar AudioRecord.setPreferredDevice() para ignorar a lógica de seleção de origem padrão do Android.

Usos de áudio

O AAOS usa principalmente AudioAttributes.AttributeUsages para roteamento, ajustes de volume e gerenciamento de foco. Os usos são representação do “porquê” a transmissão está sendo tocada. Portanto, todos os streams e solicitações de seleção de áudio devem especificar um uso para a reprodução de áudio. Quando não estiver definido especificamente na construção de um objeto AudioAttributes, o uso será definido como USAGE_UNKNOWN. No momento, isso é tratado da mesma forma como USAGE_MEDIA, esse comportamento não deve ser usado para mídia a reprodução.

Usos do sistema

No Android 11, os usos do sistema foram introduzidos. Esses usos se comportam de forma semelhante aos usos estabelecidos anteriormente, exceto pelo fato de exigirem APIs do sistema para usar, bem como android.permission.MODIFY_AUDIO_ROUTING. A nova de uso do sistema são:

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Para criar uma AudioAttributes com uso do sistema, use AudioAttributes.Builder#setSystemUsage em vez de setUsage. Chamar esse método com um uso que não seja do sistema vai resultar na geração de uma IllegalArgumentException. Além disso, se se um uso do sistema e o uso tiverem sido definidos em um builder, isso vai gerar uma IllegalArgumentException ao criar.

Para verificar qual uso está associado a um AudioAttributes por exemplo, chame AudioAttributes#getSystemUsage. Isso retorna o uso ou o uso do sistema associado.

Contextos de áudio

Para simplificar a configuração do áudio AAOS, alguns usos semelhantes foram agrupados em CarAudioContext. Esses contextos de áudio são usados CarAudioService para definir o roteamento, os grupos de volumes e a seleção de áudio de projetos.

Os contextos de áudio no Android 11 são:

Mapeamento entre contextos e usos de áudio. As linhas em destaque são para novas do sistema.

Áudio em várias zonas

Com o setor automotivo surge novos casos de uso relacionados a usuários simultâneos que interagem com a plataforma e procuram consumir mídia separada. Para exemplo, um motorista pode tocar música na cabine, enquanto os passageiros no banco traseiro estão assistindo um vídeo do YouTube na tela traseira. Com o áudio em várias zonas, permitindo que diferentes fontes de áudio sejam reproduzidas simultaneamente em diferentes áreas do veículo.

O áudio em várias zonas a partir do Android 10 permite que OEMs configurem áudio em zonas separadas. Cada zona é um conjunto de dispositivos em um veículo com grupos de volumes próprios, configuração de roteamento para contextos de projetos. Dessa forma, a cabine principal poderia ser configurada enquanto as entradas para fone de ouvido da tela traseira devem ser configuradas como uma segunda zona.

As zonas são definidas como parte de car_audio_configuration.xml. O CarAudioService lê a configuração e ajuda o AudioService encaminham streams de áudio com base na zona associada. Cada zona ainda define regras para roteamento com base em contextos e no UID dos aplicativos. Quando um jogador criado, o CarAudioService determina para qual zona o jogador associados e, com base no uso, a qual dispositivo o AudioFlinger deve rotear o áudio.

O foco também é mantido de maneira independente para cada zona de áudio. Isso permite aplicativos em zonas diferentes para produzir áudio de forma independente, sem interferindo uns nos outros enquanto os aplicativos ainda respeitem as alterações em dentro da zona. CarZonesAudioFocus em CarAudioService é responsável por gerenciar o foco de cada zona.

Figura 2. Configurar áudio em várias zonas

HAL de áudio

As implementações de áudio automotivas usam a HAL de áudio padrão do Android, que inclui o seguinte:

• IDevice.hal: Cria fluxos de entrada e saída. processa volume principal e silencia e usa:
  • createAudioPatch: Criar patches externos e externos entre dispositivos.
  • IDevice.setAudioPortConfig() para fornecer volume a cada stream físico.
• IStream.hal: Com as variantes de entrada e saída, gerencia o streaming de amostras de áudio de e para o hardware.

Tipos de dispositivos automotivos

Os tipos de dispositivos a seguir são relevantes para plataformas automotivas.

Como configurar dispositivos de áudio

Os dispositivos de áudio visíveis para o Android precisam ser definidos em /audio_policy_configuration.xml, que inclui os seguintes componentes:

• nome do módulo. Oferece suporte a "principal" (usado para casos de uso automotivos), "A2DP", "remote_submix" e "USB". O nome do módulo e o áudio correspondente O driver precisa ser compilado em audio.primary.$(variant).so.
• devicePorts. Contém uma lista de descritores de dispositivo para todas as entradas e saídas (inclui dispositivos anexados permanentemente e removíveis) que podem ser que será acessado neste módulo.
• Para cada dispositivo de saída, é possível definir um controle de ganho que consiste em Valores min/max/default/step em milibel (1 milibel = 1/100 dB = 1/1000 bel).
• O atributo address em uma instância devicePort pode ser usado para encontrar dispositivo, mesmo se houver vários aparelhos com o mesmo tipo de AUDIO_DEVICE_OUT_BUS:
• mixPorts Contém uma lista de todos os streams de saída e entrada expostos pelo HAL de áudio. Cada instância de mixPort pode ser considerada como um stream físico para o AudioService do Android.
• rotas de prioridade mais alta. Define uma lista de possíveis conexões entre entrada e saída entre dispositivos ou entre o stream e o dispositivo.

O exemplo a seguir define um dispositivo de saída bus0_phone_out em que Os streams de áudio do Android são misturados por mixer_bus0_phone_out. O trajeto usa o stream de saída de mixer_bus0_phone_out para o dispositivo bus0_phone_out.

<audioPolicyConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module name="primary" halVersion="3.0">
            <attachedDevices>
                <item>bus0_phone_out</item>
<defaultOutputDevice>bus0_phone_out</defaultOutputDevice>
            <mixPorts>
                <mixPort name="mixport_bus0_phone_out"
                         role="source"
                         flags="AUDIO_OUTPUT_FLAG_PRIMARY">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                </mixPort>
            </mixPorts>
            <devicePorts>
                <devicePort tagName="bus0_phone_out"
                            role="sink"
                            type="AUDIO_DEVICE_OUT_BUS"
                            address="BUS00_PHONE">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                    <gains>
                        <gain name="" mode="AUDIO_GAIN_MODE_JOINT"
                                minValueMB="-8400"
                                maxValueMB="4000"
                                defaultValueMB="0"
                                stepValueMB="100"/>
                    </gains>
                </devicePort>
            </devicePorts>
            <routes>
                <route type="mix" sink="bus0_phone_out"
                       sources="mixport_bus0_phone_out"/>
            </routes>
        </module>
    </modules>
</audioPolicyConfiguration>