List of prioritarized topics for the Audio HAL

Networked audio devices

• need for a better support (of the configuration) of networked audio devices.
• currently Android can view only a single device / sound card.
• an audio network in car might have multiple devices that need to be controlled by the Android OS.
• related need: a silicon vendor has a portfolio of audio processors and an automotive audio bus to distribute audio within the car, and want to configure their proprietary audio bus SW stack to use it with AA as they did for Linux
• No easy way to support external amplifiers

Source Management

configuration of automotive overlay, there is not much tool to configure the AA system

configuration management component for TinyALSA

Common Audio HAL

• (look at slides 15-20 of tech summit deck)

Audio data transfer

• streaming to a co-processor for post processing of audio from the HAL / other Android layers
• related,need: we want to determine whether we have a problem of bandwith when using our proprietary network with AA, one approach is to use shared memory transfer in the audio HAL

Equalization

• there is no way to control the equalization, i.e. no simple way to control global effects for output streams (by default Android application controls its own tracks)

Audio Calibration

• there is no Audio calibration interface

Multiple audio channels

• the challenge is to adapt the AA framework to HW I/O, e.g. there are 4 audio channels that need to be presented as 2 audio channels to AA

Early audio

• for RVC (Rear View Camera) or other services

Remark: This is addressed by the Android Automotive team here.

Source Management

• Multi‐source multi‐sink
• Stream types – not audio zones
• Still limited to one sink
• Limited number of sources

Remark: This can be addressed with the new multi-zone concept that started since Android 9.

Source Management

Audio Focus

• doesn't forbid to interrupt Audio, Android 10 provides additional interface for automotive applications to solve this problem
• Audio focus can be lost at any time

Bluetooth: patches for handsfree management, combination of BT stream with other streams, how to enable the correct audio routing, documentation on the Audio HAL is missing, it is difficult to find examples on line

Remark: This can be related to the current POC. The BT can be mixed inside or outside of Android Automotive. This should be addressed in the POC.

Android does not implement all features required by customer. (bullet points below will be distributed over the table)

• Limited number of priorities -2
• No priorities of phone call types.

Remark: It seems that the Android Automotive team is addressing this. In Android 10 there is a matrix to control the priories. For now it's hard-coded but it might get more flexibility.

Android Audio subsystem is developed only for infotainment purposes. Safety-related features need to be implemented in another RTOS

• Need to share the same hardware between 2 OSes
• Running Android as a virtual machine inside RTOS leads to problems with scheduling of audio processes

Remark: This can be tackled in the POC. This going towards the other extreme of making a system outside of Android to control safety-related features. It should be address in the POC as well.

Android way of extending its functionality is developing vendor extensions without modification of the framework.

• But in some cases you need to modify framework. There is a process for this, but slow. And changes needed to one customer / developer is not needed for another. Even if you do this, you have to wait until Tier 1 merges this change to its drop
• You have to retain compatibility for third-party apps

• Google is still very “hand wavy” about solution

• WR: Highly modified HAL, “virtual sources”, policy/focus management, flexible – data‐driven

• Last two‐miles left to IVI developer

• (Android P improvements?) …more churn?

• Genivi?