Audio para automóviles

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El SO Android Automotive (AAOS) se basa en la pila de audio principal de Android para admitir los casos de uso de funcionamiento como sistema de infoentretenimiento en un vehículo. AAOS es responsable de los sonidos de infoentretenimiento (es decir, medios, navegación y comunicaciones), pero no es directamente responsable de las campanillas y advertencias que tienen requisitos estrictos de disponibilidad y tiempo. Si bien el AAOS proporciona indicadores y mecanismos para ayudar al vehículo a administrar el audio, en última instancia, depende del vehículo decidir qué sonidos se deben reproducir para el conductor y los pasajeros, lo que garantiza que los sonidos esenciales para la seguridad y los sonidos reglamentarios se escuchen correctamente sin interrupciones.

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

Android 11 incluye los siguientes cambios en la compatibilidad con audio relacionado con la industria automotriz:

• Selección automática de la zona de audio según el ID de usuario asociado
• Nuevos usos del sistema para admitir sonidos específicos de la industria automotriz
• Compatibilidad con el enfoque de audio de HAL
• Enfoque de audio retrasado para transmisiones no transitorias
• 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 para vehículos controlan los siguientes sonidos y transmisiones:

Figura 1: Diagrama de arquitectura centrada en el flujo

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

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

Para garantizar la confiabilidad, los sonidos externos (que provienen de fuentes independientes, como las campanillas de advertencia del cinturón de seguridad) se administran fuera de Android, debajo de la HAL o incluso en hardware independiente. Los implementadores del sistema deben proporcionar un mezclador que acepte una o más transmisiones de entrada de sonido de Android y, luego, combine esas transmisiones de una manera adecuada con las fuentes de sonido externas que requiere el vehículo.

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

Sonidos de Android

Las apps pueden tener uno o más reproductores que interactúan a través de las APIs estándar de Android (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 pueden ser mono de un solo canal o envolvente 7.1, pero se enrutan y se tratan como una sola fuente. La transmisión de la app está asociada con AudioAttributes, que le dan al sistema sugerencias 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 (y solo una) de las transmisiones de salida físicas disponibles, cada una de las cuales es la salida de un mezclador dentro de AudioFlinger. Después de 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 HAL de audio para renderizar en el hardware. En las apps para la industria automotriz, el hardware de renderización puede ser codecs locales (similares a los dispositivos móviles) o un procesador remoto en la red física del vehículo. De cualquier manera, es la tarea de la implementación de HAL de audio entregar los datos de muestra reales y hacer que sean audibles.

Transmisiones externas

Las transmisiones de sonido que no se deben enrutar a través de Android (por motivos de certificación o de tiempo) se pueden enviar directamente al mezclador externo. A partir de Android 11, el HAL ahora puede solicitar el enfoque de estos sonidos externos para informar a Android de modo que pueda tomar las medidas adecuadas, como pausar el contenido multimedia o evitar que otros elementos se enfoquen.

Si las transmisiones externas son fuentes de contenido 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 app para Android. Dicha app solicitaría el enfoque de audio en nombre de la fuente de contenido multimedia en lugar del HAL y respondería a las notificaciones de enfoque iniciando o deteniendo la fuente externa según sea necesario para adaptarse a la política de enfoque de Android. La app también es responsable de controlar los eventos clave de contenido multimedia, como reproducir o pausar. Un mecanismo sugerido para controlar esos 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 para vehículos. El dispositivo de bus admite puertos direccionables (en los que cada puerto es el extremo de una transmisión 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 cuyo caso Android mezcla todo y lo entrega como un flujo. Como alternativa, el HAL puede proporcionar un puerto de bus para cada CarAudioContext para permitir la entrega simultánea de cualquier tipo de sonido. Esto permite que la implementación de HAL combine y baje los diferentes sonidos según se 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

Cuando se captura audio, el HAL de audio 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, Asistente de Google) espera una transmisión de micrófono estéreo que tenga un efecto de cancelación de eco (si está disponible), pero que no se le aplique ningún otro procesamiento. Se espera que el Asistente realice el enfocamiento de haces.

Entrada de micrófono multicanal

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

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, se ignoran las fuentes virtuales, como AUDIO_SOURCE_FM_TUNER, y, por lo tanto, se pueden capturar de forma simultánea junto con una entrada normal (como el micrófono). HwAudioSources tampoco se consideran parte de las restricciones de captura simultáneas.

Las apps diseñadas para funcionar con dispositivos AUDIO_DEVICE_IN_BUS o con dispositivos AUDIO_DEVICE_IN_FM_TUNER secundarios deben identificar esos dispositivos de forma explícita y usar AudioRecord.setPreferredDevice() para omitir la lógica de selección de fuente predeterminada de Android.

Usos de audio

AAOS usa principalmente AudioAttributes.AttributeUsages para el enrutamiento, los ajustes de volumen y la administració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. Si no se establece de forma específica cuando se compila un objeto AudioAttributes, el uso se establecerá de forma predeterminada en USAGE_UNKNOWN. Si bien, en la actualidad, se trata de la misma manera que USAGE_MEDIA, no se debe confiar en este comportamiento para la reproducción de contenido multimedia.

Usos del sistema

En Android 11, se introdujeron los usos del sistema. Estos usos se comportan de manera similar a los establecidos anteriormente, excepto que requieren que se usen las APIs del sistema, además de android.permission.MODIFY_AUDIO_ROUTING. Los nuevos usos del sistema son los siguientes:

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Para crear un AudioAttributes con un uso del sistema, usa AudioAttributes.Builder#setSystemUsage en lugar de setUsage. Si llamas a este método con un uso que no sea del sistema, se arrojará un IllegalArgumentException. Además, si se configuró un uso del sistema y un uso en un compilador, se arrojará un IllegalArgumentException durante la compilación.

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

Contextos de audio

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

Los contextos de audio en Android 11 son los siguientes:

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

Audio multizona

Con la industria automotriz, se presenta un nuevo conjunto de casos de uso sobre usuarios simultáneos que interactúan con la plataforma y buscan consumir contenido multimedia independiente. Por ejemplo, el conductor puede reproducir música en la cabina mientras los pasajeros del asiento trasero miran un video de YouTube en la pantalla trasera. El audio multizona permite que se reproduzcan diferentes fuentes de audio de forma simultánea en diferentes áreas del vehículo.

El audio multizona que se incluye a partir de Android 10 permite a los OEMs configurar el audio en zonas separadas. Cada zona es un conjunto de dispositivos dentro del vehículo con sus propios grupos de volumen, configuración de enrutamiento para contextos y administración de enfoque. De esta manera, la cabina principal se puede configurar como una zona de audio, mientras que los conectores para auriculares de la pantalla trasera se pueden configurar 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 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 con qué zona está asociado y, luego, en función del 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 de diferentes zonas produzcan audio de forma independiente sin interferir entre sí, a la vez que las aplicaciones siguen respetando los cambios de enfoque dentro de su zona. CarZonesAudioFocus dentro de CarAudioService es responsable de administrar el enfoque de cada zona.

Figura 2: Cómo configurar el audio multizona

HAL de audio

Las implementaciones de audio para vehículos dependen de la HAL de audio estándar de Android, que incluye lo siguiente:

• IDevice.hal: Crea flujos de entrada y salida, controla el volumen principal y la función de silenciamiento, y usa lo siguiente:
  • createAudioPatch: Para crear parches externos entre dispositivos.
  • IDevice.setAudioPortConfig() para proporcionar volumen para 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.

Tipos de dispositivos para la industria automotriz

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 se deben definir en /audio_policy_configuration.xml, que incluye los siguientes componentes:

• nombre del módulo. Admite "primary" (se usa para casos de uso de Automotive), "A2DP", "remote_submix" y "USB". El nombre del módulo y el controlador de audio correspondiente deben compilarse en audio.primary.$(variant).so.
• devicePorts. Contiene una lista de descriptores de dispositivos para todos los dispositivos de entrada y salida (incluye dispositivos conectados de forma permanente y dispositivos extraíbles) a los que se puede acceder desde este módulo.
• Para cada dispositivo de salida, puedes definir el control de ganancia que consta de valores mínimos, máximos, predeterminados o de paso en milibelios (1 milibelio = 1/100 dB = 1/1000 bel).
• El atributo address 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.
• mixPorts. Contiene una lista de todas las transmisiones de entrada y salida que expone el HAL de audio. 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 transmisiones y dispositivos.

En el siguiente ejemplo, se define un dispositivo de salida bus0_phone_out en el que mixer_bus0_phone_out mezcla todas las transmisiones de audio de Android. La ruta toma la transmisión 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>