Audio automotriz

El sistema operativo Android Automotive (AAOS) se basa en la pila de audio central de Android para admitir casos de uso para operar como sistema de información y entretenimiento en un vehículo. AAOS es responsable de los sonidos de información y entretenimiento (es decir, medios, navegación y comunicaciones), pero no es directamente responsable de los timbres y advertencias que tienen requisitos estrictos de disponibilidad y sincronización. Si bien AAOS proporciona señales y mecanismos para ayudar al vehículo a gestionar el audio, al final depende del vehículo decidir qué sonidos deben reproducirse para el conductor y los pasajeros, garantizando que los sonidos críticos para la seguridad y los sonidos regulatorios se escuchen correctamente sin interrupción.

A medida que Android administra la experiencia multimedia del vehículo, las fuentes multimedia externas, como el sintonizador de radio, deben estar representadas por aplicaciones que puedan manejar el enfoque de audio y los eventos clave multimedia para la fuente.

Android 11 incluye los siguientes cambios en la compatibilidad con audio relacionado con el automóvil:

• Selección automática de zona de audio basada en la ID de usuario asociada
• Nuevos usos del sistema para admitir sonidos específicos de automóviles
• Soporte de enfoque de audio HAL
• Enfoque de audio retrasado para transmisiones no transitorias
• Configuración de usuario para controlar la interacción entre navegación y llamadas.

Sonidos y transmisiones de Android

Los sistemas de audio automotrices manejan los siguientes sonidos y transmisiones:

Figura 1. Diagrama de arquitectura centrada en la transmisión

Android administra los sonidos provenientes de las aplicaciones de Android, controla esas aplicaciones y enruta sus sonidos a dispositivos de salida en el HAL según el tipo de sonido:

• Las transmisiones lógicas , conocidas como fuentes en la nomenclatura principal de audio, están etiquetadas con atributos de audio .
• Las transmisiones físicas , conocidas como dispositivos en la nomenclatura básica de audio, no tienen información de contexto después de la mezcla.

Para mayor confiabilidad, los sonidos externos (procedentes de fuentes independientes, como campanas de advertencia del cinturón de seguridad) se administran fuera de Android, debajo de HAL o incluso en hardware separado. Los implementadores del sistema deben proporcionar un mezclador que acepte uno o más flujos de entrada de sonido desde Android y luego combine esos flujos de manera adecuada con las fuentes de sonido externas requeridas por el vehículo.

La implementación HAL y el mezclador externo son responsables de garantizar que se escuchen los sonidos externos críticos para la seguridad y de mezclar las transmisiones proporcionadas por Android y enrutarlas a los parlantes adecuados.

sonidos de android

Las aplicaciones pueden tener uno o más reproductores que interactúan a través de las API estándar de Android (por ejemplo, AudioManager para control de enfoque o MediaPlayer para transmisión) para emitir uno o más flujos lógicos de datos de audio. Estos datos pueden ser monocanal mono o envolvente 7.1, pero se enrutan y tratan como una única fuente. La transmisión de la aplicación está asociada con AudioAttributes que le dan al sistema sugerencias sobre cómo se debe expresar el audio.

Los flujos lógicos se envían a través de AudioService y se enrutan a uno (y solo uno) de los flujos de salida físicos disponibles, cada uno de los cuales es la salida de un mezclador dentro de AudioFlinger. Una vez que los atributos de audio se hayan mezclado en una transmisión física, ya no estarán disponibles.

Luego, cada transmisión física se entrega al Audio HAL para su renderización en el hardware. En las aplicaciones automotrices, el hardware de renderizado puede ser códecs locales (similares a los dispositivos móviles) o un procesador remoto a través de la red física del vehículo. De cualquier manera, el trabajo de la implementación de Audio HAL es entregar los datos de muestra reales y hacer que se vuelvan audibles.

Corrientes externas

Las transmisiones de sonido que no deberían enrutarse a través de Android (por razones de certificación o tiempo) pueden enviarse directamente al mezclador externo. A partir de Android 11, HAL ahora puede solicitar enfoque para estos sonidos externos para informar a Android de modo que pueda tomar las acciones apropiadas, como pausar medios o evitar que otros obtengan enfoque.

Si las transmisiones externas son fuentes multimedia que deben interactuar con el entorno de sonido que genera Android (por ejemplo, detener la reproducción de MP3 cuando se enciende un sintonizador externo), esas transmisiones externas deben estar representadas por una aplicación de Android. Una aplicación de este tipo solicitaría enfoque de audio en nombre de la fuente de medios en lugar de HAL, y respondería a las notificaciones de enfoque iniciando/deteniendo la fuente externa según sea necesario para ajustarse a la política de enfoque de Android. La aplicación también es responsable de manejar eventos clave de medios como reproducción/pausa. Un mecanismo sugerido para controlar dichos dispositivos externos es HwAudioSource .

Dispositivos de salida

En el nivel Audio HAL, el tipo de dispositivo AUDIO_DEVICE_OUT_BUS proporciona un dispositivo de salida genérico para usar en sistemas de audio de vehículos. El dispositivo de bus admite puertos direccionables (donde cada puerto es el punto final de un flujo físico) y se espera que sea el único tipo de dispositivo de salida admitido en un vehículo.

Una implementación de sistema puede usar un puerto de bus para todos los sonidos de Android, en cuyo caso Android mezcla todo y lo entrega como una sola transmisión. Alternativamente, HAL puede proporcionar un puerto de bus para cada CarAudioContext para permitir la entrega simultánea de cualquier tipo de sonido. Esto hace posible que la implementación HAL mezcle y atenúe los diferentes sonidos como desee.

La asignación de contextos de audio a dispositivos de salida se realiza a través de car_audio_configuration.xml .

Entrada de micrófono

Al capturar audio, Audio HAL recibe una llamada openInputStream que incluye un argumento AudioSource que indica cómo se debe procesar la entrada del micrófono.

La fuente VOICE_RECOGNITION (específicamente el Asistente de Google) espera una transmisión de micrófono estéreo que tiene un efecto de cancelación de eco (si está disponible), pero no se le aplica ningún otro procesamiento. Se espera que el Asistente realice la formación de haces.

Entrada de micrófono multicanal

Para capturar audio desde un dispositivo con más de dos canales (estéreo), use una máscara de índice de canal en lugar de una máscara de índice posicional (como CHANNEL_IN_LEFT ). Ejemplo:

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

Cuando se configuran setChannelMask y setChannelIndexMask , AudioRecord usa solo el valor establecido por setChannelMask (máximo de dos canales).

captura concurrente

A partir de Android 10, el marco de Android admite la captura simultánea de entradas, pero con restricciones para proteger la privacidad del usuario. Como parte de estas restricciones, las fuentes virtuales como AUDIO_SOURCE_FM_TUNER se ignoran y, como tales, se permite capturarlas simultáneamente junto con una entrada normal (como el micrófono). HwAudioSources tampoco se considera parte de las restricciones de captura simultánea.

Las aplicaciones diseñadas para funcionar con dispositivos AUDIO_DEVICE_IN_BUS o con dispositivos AUDIO_DEVICE_IN_FM_TUNER secundarios deben depender de la identificación explícita de esos dispositivos y del uso AudioRecord.setPreferredDevice() para omitir la lógica de selección de fuente predeterminada de Android.

Usos de audio

AAOS utiliza principalmente AudioAttributes.AttributeUsages para enrutamiento, ajustes de volumen y gestión de enfoque. Los usos son una representación del "por qué" se reproduce la transmisión. Por lo tanto, todas las transmisiones y solicitudes de enfoque de audio deben especificar un uso para su reproducción de audio. Cuando no se establece específicamente al crear un objeto AudioAttributes, el uso predeterminado será USAGE_UNKNOWN . Si bien actualmente esto se trata de la misma manera que USAGE_MEDIA , no se debe confiar en este comportamiento para la reproducción multimedia.

Usos del sistema

En Android 11, se introdujeron los usos del sistema. Estos usos se comportan de manera similar a los usos establecidos anteriormente, excepto que requieren API del sistema para su uso, así como android.permission.MODIFY_AUDIO_ROUTING . Los nuevos usos del sistema son:

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Para construir un AudioAttributes con un uso del sistema, use AudioAttributes.Builder#setSystemUsage en lugar de setUsage . Llamar a este método con un uso que no sea del sistema dará como resultado que se genere una IllegalArgumentException . Además, si se han configurado tanto el uso del sistema como el uso en un constructor, se generará una IllegalArgumentException al compilar.

Para verificar qué uso está asociado con una instancia AudioAttributes , llame a AudioAttributes#getSystemUsage . Esto devuelve el uso o uso del sistema asociado.

Contextos de audio

Para simplificar la configuración del audio AAOS, se han agrupado usos similares en CarAudioContext . Estos contextos de audio se utilizan en todo CarAudioService para definir enrutamiento, grupos de volumen y administración de enfoque de audio.

Los contextos de audio en Android 11 son:

Mapeo entre contextos y usos de audio. Las filas resaltadas son para nuevos usos del sistema .

Audio multizona

Con la automoción surge un nuevo conjunto de casos de uso en torno a usuarios simultáneos que interactúan con la plataforma y buscan consumir medios separados. Por ejemplo, un conductor puede reproducir música en la cabina mientras los pasajeros del asiento trasero ven un vídeo de YouTube en la pantalla trasera. El audio multizona permite esto al permitir que diferentes fuentes de audio se reproduzcan simultáneamente en diferentes áreas del vehículo.

El audio multizona a partir de Android 10 permite a los OEM configurar el audio en zonas separadas. Cada zona es una colección de dispositivos dentro del vehículo con sus propios grupos de volumen, configuración de rutas para contextos y gestión de enfoque. De esta manera, el habitáculo principal podría configurarse como una zona de audio, mientras que las tomas de auriculares de la pantalla trasera se podrían configurar como una segunda zona.

Las zonas se definen como parte de car_audio_configuration.xml . CarAudioService luego lee la configuración y ayuda a AudioService a enrutar transmisiones de audio según su zona asociada. Cada zona aún define reglas para el enrutamiento según los contextos y el uid de las aplicaciones. Cuando se crea un reproductor, CarAudioService determina a qué zona está asociado el reproductor y luego, según el uso, a qué dispositivo AudioFlinger debe enrutar el audio.

El enfoque también se mantiene de forma independiente para cada zona de audio. Esto permite que las aplicaciones en diferentes zonas produzcan audio de forma independiente sin interferir entre sí y al mismo tiempo hacer que las aplicaciones respeten los cambios de enfoque dentro de su zona. CarZonesAudioFocus dentro de CarAudioService es responsable de gestionar el enfoque para cada zona.

Figura 2. Configurar audio multizona

AudioHAL

Las implementaciones de audio para automóviles se basan en el estándar Android Audio HAL, que incluye lo siguiente:

• IDevice.hal . Crea flujos de entrada y salida, maneja el volumen principal y el silenciamiento, y utiliza:
  • createAudioPatch . Para crear parches externos-externos entre dispositivos.
  • IDevice.setAudioPortConfig() para proporcionar volumen para cada transmisión física.
• IStream.hal . Junto con las variantes de entrada y salida, gestiona la transmisión de muestras de audio hacia y desde el hardware.

Tipos de dispositivos automotrices

Los siguientes tipos de dispositivos son relevantes para plataformas automotrices.

Configurar dispositivos de audio

Los dispositivos de audio visibles para Android deben definirse en /audio_policy_configuration.xml , que incluye los siguientes componentes:

• Nombre del módulo. Admite "primario" (utilizado para casos de uso automotriz), "A2DP", "remote_submix" y "USB". El nombre del módulo y el controlador de audio correspondiente deben compilarse en audio.primary.$(variant).so .
• puertos del dispositivo. Contiene una lista de descriptores de dispositivos para todos los dispositivos de entrada y salida (incluye dispositivos conectados permanentemente y dispositivos extraíbles) a los que se puede acceder desde este módulo.
• Para cada dispositivo de salida, puede definir un control de ganancia que consta de valores mínimo/máximo/predeterminado/paso en milibelios (1 milibelio = 1/100 dB = 1/1000 belio).
• El atributo de dirección en una instancia de devicePort se puede usar para encontrar el dispositivo, incluso si hay varios dispositivos con el mismo tipo de dispositivo que AUDIO_DEVICE_OUT_BUS .
• puertos mixtos. Contiene una lista de todos los flujos de salida y entrada expuestos por el audio HAL. Cada instancia de mixPort se puede considerar como una transmisión física a Android AudioService.
• rutas. Define una lista de posibles conexiones entre dispositivos de entrada y salida o entre flujo y dispositivo.

El siguiente ejemplo define un dispositivo de salida bus0_phone_out en el que mezclador_bus0_phone_out mezcla todas las transmisiones de audio de Android. La ruta lleva el flujo de salida de mixer_bus0_phone_out al 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>