Audio para automóviles

El SO Android Automotive (AAOS) se basa en la pila de audio principal de Android para admitir los casos de uso para funcionar como sistema de infoentretenimiento en un vehículo. AAOS es responsable de los sonidos de infoentretenimiento (es decir, contenido multimedia, navegación y comunicaciones, pero no es directamente responsable de las campanillas y advertencias que tengan estrictos requisitos de disponibilidad y tiempo. Si bien el AAOS proporciona indicadores y mecanismos para ayudar al vehículo a administrar el audio; al final, depende del vehículo para determinar qué sonidos se deben reproducir para el conductor pasajeros, garantizando que los sonidos críticos de seguridad y regulatorios funcionen correctamente escucharse sin interrupciones.

Como Android administra la experiencia multimedia del vehículo, las fuentes de contenido multimedia externas como el sintonizador de radio, deben estar representados por apps que puedan procesar audio el enfoque y los eventos clave multimedia de la fuente.

Android 11 incluye los siguientes cambios en el audio relacionado con automóviles soporte:

• Selección automática de zonas de audio según el ID del usuario asociado
• Nuevos usos del sistema para admitir sonidos específicos de automóviles
• Compatibilidad con foco de audio de HAL
• Enfoque de audio retrasado para transmisiones no transitorias
• Parámetro de configuración del usuario para controlar la interacción entre la navegación y las llamadas

Sonidos y transmisiones de Android

Los sistemas de audio de Automotive admiten los siguientes sonidos y transmisiones:

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

Android controla y controla los sonidos que provienen de las apps para Android y enrutar sus sonidos a los dispositivos de salida en la HAL según el tipo sonido:

• Transmisiones lógicas, conocidas como fuentes en el audio principal se etiquetan con Atributos de audio.
• Transmisiones físicas, conocidas como dispositivos en el audio principal nomenclatura, no tienen información de contexto después de la mezcla.

Para la confiabilidad, se pueden usar los sonidos externos (provenientes de fuentes fuentes, como la campanilla del cinturón de seguridad) se administran fuera de Android, debajo del HAL o incluso en hardware independiente. Los implementadores de sistemas deben proporcionar un mezclador acepta una o más transmisiones de entrada de sonido de Android y luego las combina de forma adecuada con las fuentes de sonido externas requeridas por vehículo.

La implementación de HAL y el mezclador externo son responsables de garantizar que los sonidos externos críticos para la seguridad y para mezclar en los transmisiones continuas y enrutarlas a las bocinas adecuadas.

Sonidos de Android

Las apps pueden tener uno o más reproductores que interactúen mediante la versión estándar de Android. APIs (por ejemplo, AudioManager para el control de enfoque o MediaPlayer para la transmisión) para emitir una o más transmisiones lógicas de datos de audio. Estos datos puede ser monocanal o envolvente 7.1, pero se enruta y trata como un fuente única. La transmisión de aplicaciones se asocia con AudioAttributes. que le proporcionan sugerencias al sistema sobre cómo se debe expresar el audio.

Las transmisiones lógicas se envían a través de AudioService y se enrutan a una una sola) de las transmisiones de salida físicas disponibles, cada una de las cuales es la de un mezclador en AudioFlinger. Después de mezclar los atributos de audio a una transmisión física, ya no están disponibles.

Luego, cada transmisión física se entrega a la HAL de audio para que se renderice el hardware. En apps para vehículos, el hardware de procesamiento puede ser códecs locales. (similar a los dispositivos móviles) o un procesador remoto en toda la infraestructura física del vehículo en cada red. De cualquier manera, la tarea de la implementación de la HAL de audio es proporcionar el datos de muestra reales y hacer que sean audibles.

Transmisiones externas

Transmisiones de sonido que no se deben enrutar a través de Android (para certificación o de tiempo) se pueden enviar directamente a la mezcladora externa. A partir de Android 11, la HAL ahora puede solicitar foco para estos sonidos externos para informar a Android para que pueda tomar las medidas adecuadas, como detener contenido multimedia o evitar que otros se enfoquen.

Si las transmisiones externas son fuentes multimedia que deberían interactuar con el sonido de producción que genera Android (por ejemplo, detener la reproducción de MP3 cuando se un sintonizador externo está activado), esas transmisiones externas deben estar representadas App para Android Este tipo de app solicitaría el foco de audio en nombre de la fuente de contenido multimedia en lugar de la HAL, y respondería a las notificaciones de enfoque iniciar/detener la fuente externa según sea necesario para ajustarse al enfoque de Android . La app también es responsable de controlar los eventos clave de contenido multimedia, reproducir/pausar. Un mecanismo sugerido para controlar estos dispositivos externos es HwAudioSource.

Dispositivos de salida

En el nivel de la HAL de audio, 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 autobús el dispositivo admite puertos direccionables (donde cada puerto es el extremo de un física) y se espera que sea el único tipo de dispositivo de salida compatible en un vehículo.

Una implementación del sistema puede usar un puerto de bus para todos los sonidos de Android, en en cuyo caso Android mezcla todo y lo entrega como una sola transmisión. Como alternativa, la HAL puede proporcionar un puerto de bus para cada CarAudioContext a fin de permitir y entrega simultánea de cualquier tipo de sonido. Esto hace posible que la HAL para mezclar y atenuar los diferentes sonidos como desees.

La asignación de contextos de audio a los dispositivos de salida se realiza mediante car_audio_configuration.xml

Entrada de micrófono

Al capturar audio, la HAL de audio recibe un openInputStream. llamada 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 con un efecto de cancelación del eco (si está disponible), pero no se aplicó ningún otro procesamiento. Se espera que Asistente realice la conformación de haces.

Entrada de micrófono multicanal

Para capturar audio de un dispositivo con más de dos canales (estéreo), usa un 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 setChannelMask y setChannelIndexMask se establecen, AudioRecord usa solo el valor establecido por setChannelMask (dos canales como máximo).

Captura simultánea

A partir de Android 10, el framework 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 ignorarán y, por lo tanto, se podrán se capturan de forma simultánea junto con una entrada normal (como el micrófono). Las HwAudioSources tampoco se consideran parte de operaciones simultáneas. de captura.

Apps diseñadas para funcionar con dispositivos de AUDIO_DEVICE_IN_BUS o con los dispositivos AUDIO_DEVICE_IN_FM_TUNER secundarios deben depender explícitamente identificar esos dispositivos y usar AudioRecord.setPreferredDevice() para omitir la lógica de selección de fuentes predeterminada de Android.

Usos de audio

El AAOS utiliza principalmente AudioAttributes.AttributeUsages para el enrutamiento, los ajustes de volumen y la gestión del enfoque. Los usos son un del “por qué” se está reproduciendo la transmisión. Por lo tanto, todas las transmisiones y las solicitudes de foco de audio deben especificar un uso para su reproducción de audio. Cuándo no se establece específicamente cuando se compila un objeto AudioAttributes, el uso se se estableció de forma predeterminada en USAGE_UNKNOWN. Aunque actualmente se trata de la misma forma como USAGE_MEDIA, no se debe confiar en este comportamiento para el contenido multimedia. reproducción.

Usos del sistema

En Android 11, se introdujeron los usos del sistema. Estos usos se comportan de manera similar a los usos establecidos anteriormente, con la excepción de que requieren APIs del sistema para usar, así como android.permission.MODIFY_AUDIO_ROUTING. La nueva herramienta usos del sistema son:

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Para construir un objeto AudioAttributes con un uso del sistema, usa AudioAttributes.Builder#setSystemUsage en lugar de setUsage. Llamar a este método con un uso que no es del sistema Se arrojará una IllegalArgumentException. Además, si se establecieron un uso del sistema y uno de uso en un compilador, se arrojará un IllegalArgumentException durante la compilación.

Para comprobar qué uso está asociado con un AudioAttributes llamada a AudioAttributes#getSystemUsage. Esto muestra el uso, o bien el uso del sistema, asociado.

Contextos de audio

Para simplificar la configuración de audio AAOS, se agruparon usos similares CarAudioContext. Estos contextos de audio se usan a lo largo CarAudioService para definir el enrutamiento, los grupos de volumen y el foco de audio y administración de posturas.

Los contextos de audio en Android 11 son los siguientes:

Asignación entre contextos de audio y usos. Las filas destacadas son para los nuevos usos del sistema.

Audio multizona

Con la industria automotriz, se presenta un nuevo conjunto de casos de uso en torno a usuarios simultáneos que interactúan con la plataforma y que buscan consumir contenido multimedia independiente. Para Por ejemplo, un conductor puede reproducir música en el asiento trasero mientras los pasajeros están en el asiento trasero están mirando un video de YouTube en la pantalla posterior. El audio multizona permite ya que permite reproducir varias fuentes de audio de forma simultánea en distintas áreas. del vehículo.

El audio multizona a partir de Android 10 permite que los OEM configuren el audio en zonas separadas. Cada zona es un conjunto de dispositivos dentro del vehículo con sus propios grupos de volúmenes, la configuración de enrutamiento para los contextos y y administración de posturas. De esta manera, la cabina principal se podría configurar como una sola cámara de audio. mientras que los conectores para auriculares de la pantalla posterior se configuran como una segunda zona.

Las zonas se definen como parte de car_audio_configuration.xml. Luego, CarAudioService lee la configuración y ayuda a AudioService enrutan transmisiones de audio según su zona asociada. Cada zona aún define reglas de enrutamiento basadas en contextos y el UID de la aplicación. Cuando un jugador es cuando se crea, CarAudioService determina la zona en la que se encuentra el jugador asociado y, luego, según el uso, con qué dispositivo el AudioFlinger a la que se debe enrutar el audio.

El enfoque también se mantiene de forma independiente para cada zona de audio. Esto permite aplicaciones en diferentes zonas para producir audio de forma independiente sin interfieran entre sí mientras hacen que las aplicaciones respeten los cambios el enfoque en su zona. CarZonesAudioFocus en un radio de CarAudioService es responsable de administrar el enfoque de cada zona.

Figura 2: Configura el audio multizona

HAL de audio

Las implementaciones de audio de Automotive se basan en la HAL de audio estándar de Android. que incluye lo siguiente:

• IDevice.hal Crea transmisiones de entrada y salida. controla el volumen y el silenciamiento principales, y usa lo siguiente:
  • createAudioPatch Para crear parches externos y externos entre dispositivos.
  • IDevice.setAudioPortConfig() para proporcionar volumen a cada transmisión física.
• IStream.hal Junto con las variantes de entrada y salida, administra la transmisión de muestras de audio hacia y desde el hardware.

Industria automotriz: tipo de dispositivos

Los siguientes tipos de dispositivos son relevantes para las plataformas de la industria automotriz.

Cómo 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. Compatible con "principal" (se usa para casos de uso de la industria automotriz), "A2DP", "remote_submix" y "USB". El nombre del módulo y el audio correspondiente El controlador debe compilarse en audio.primary.$(variant).so.
• devicePorts. Contiene una lista de descriptores de dispositivos para todas las entradas y salidas de dispositivos (incluidos los dispositivos conectados de forma permanente y los extraíbles) que se pueden a las que se accede desde este módulo.
• Para cada dispositivo de salida, puedes definir un control de ganancia que consta de valores mínimos, máximos, predeterminados y de pasos en milibeles (1 milibel = 1/100 dB = 1/1000 bel).
• El atributo address en una instancia devicePort se puede usar para encontrar la , incluso si existen varios con el mismo tipo de dispositivo que AUDIO_DEVICE_OUT_BUS
• mixPorts. Contiene una lista de todas las transmisiones de salida y entrada que expone la de audio. Cada instancia de mixPort puede considerarse como una transmisión física a Android AudioService
• rutas. Define una lista de posibles conexiones entre la entrada y la salida o entre la transmisión y el dispositivo.

En el siguiente ejemplo, se define un dispositivo de salida bus0_phone_out en el que Las transmisiones de audio de Android se mezclan con mixer_bus0_phone_out. La ruta toma 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>