Car audio service uses the Core Audio dynamic audio policy to facilitate use cases in cars.
Separate audio playback for each passenger, referred to as multi-zone audio, in which each zone allows for the concurrent playback of sound.
Dynamic audio zone configuration.
Passenger primary zone audio cast.
Passenger's audio mirror.
In each use case, the car audio service uses the dynamic audio policy to automatically route audio to the designated output device.
Multi-zone audio
Multi-zone audio enables multiple users to simultaneously interact with AAOS. A set of output devices is associated with a zone, and each zone maintains audio focus and volume level. Passengers can listen to their audio while the driver listens to another source in the primary zone (typically, the main cabin).
Multi-zone audio architecture
Figure 1. Car audio service architecture.
Car audio zones are an abstraction of audio outputs, audio focus, and other audio settings, all of which can be managed independently. For routing purposes, each zone is defined as a set of audio output bus devices as arranged in the audio policy configuration. The devices differ for each audio zone definition. In Figure 1, bus devices 1 through 5 belong to zone zero, bus devices 6 through 8 belong to zone one, and bus devices 9 through 11 belong to zone two.
Car audio configuration
Typically, output devices are assigned to one audio zone. Each audio zone is
defined in car_audio_configuration.xml. The following code snippet shows a car
audio configuration for Figure 1:
<carAudioConfiguration version="3">
<zones>
<zone name="Zone0" audioZneId="0" occupantZoneId="0">
<zoneConfigs>
<zoneConfig name="config0" isDefault="true">
<volumeGoups>
<group>
<device address="bus_1">
<context context="music"/>
</device>
</group>
<group>
<device address="bus_2">
<context context="navigation"/>
</device>
</group>
...
</volumeGroups>
</zoneConfig>
</zoneConfigs>
</zone>
<zone name="Zone1" audioZoneId="1" occupantZoneId="1">
<zoneConfigs>
<zoneConfig name="config0" isDefault="true">
<volumeGroups>
<group>
<device address="bus_6">
<context context="music"/>
</device>
</group>
<group>
<device address="bus_7">
<context context="navigation"/>
</device>
</group>
...
</volumeGroups>
</zoneConfig>
</zoneConfigs>
</zone>
...
...
</zones>
</carAudioConfiguration>
occupantZoneId is a car service definition managed by
CarOccupantZoneManager. It's used in cars to define a mapping for a user in
the car to a specific seat location. CarOccupantZoneService also defines
mapping from occupant zone to displays, other peripherals, and the user once the
user logs into a display. An audio zone has:
An audio zone ID and an occupant zone ID.
- Maps audio zone to occupant zone (seat, displays, and other peripherals)
- Map which user ID is assigned with an audio zone upon logging in
A list of audio configurations. Each audio configuration has a set of volume groups. Each volume group has a set of audio bus devices.
When volume is changed, all audio devices in a group are controlled in the same way.
Each audio device is assigned a list of audio attributes. This information is used to construct the audio policy mixes with differently assigned audio attributes.
This configuration allows different audio attribute usages to be routed to different output devices in each zone. Depending on the use case, different sounds can play concurrently. For example, you can choose to configure the main cabin (primary zone) to play media sounds on all speakers but navigation sounds only on the speakers nearest the driver. With concurrent playback of sound, the main cabin continues to listen to media while navigation is delivered to the driver.
Multi-zone audio passenger login workflow
The sequence diagram below shows the flow for enabling the audio routing when a passenger logs into their respective display:
Figure 2.
In this sequence, the user login is propagated to the car audio service via the occupant zone service.
The car audio service (for a specific audio zone) uses the
AudioPolicy#removeUserIdDeviceAffinityAPI to remove the user device affinities. This API takes a user ID. In this case, the previous zone's user.The
AudioPolicy#setUserIdDeviceAffinityAPI assigns the new user to a zone, which takes in the user ID and all devices for a specific zone configuration.
Dynamic zone configurations
In Android 14, dynamic zone configurations are introduced to allow OEMs to configure different sets of devices for passengers. The use case allows passengers in the rear seat to switch between a rear seat headrest speaker and a rear seat headphone peripheral.
In this case, two configurations are required. One each for the rear seat headrest and the headphone peripheral. Audio for a specific user is routed only to one configuration at a time.
Figure 3. Dynamic zone configuration workflow.
Figure 3 illustrations the architecture for the dynamic zone configuration
workflow. Audio zone 1 contains two configurations, Config 0 and Config 1,
which are associated with the output device speaker and headrest, respectively.
Upon logging in, the user is automatically assigned the default configuration. When the user elects to change configurations, usually through a system UI, the car audio service executes the switch between the two configurations. In this way, the output device is switched between the Z1 speaker and the Z1 headrest.
The code snippet below shows the setup for this dynamic zone configuration.
<carAudioConfiguration version="3">
<zones>
<zone name="Zone1" audioZoneId="1" occupantZoneId="1">
<zoneConfigs>
<zoneConfig name="Zone 1 Config 0" isDefault="true">
<volumeGroups>
<group>
<device address="bus_100">
<context context="music"/>
***
</device>
</group>
</volumeGroups>
</zoneConfig>
<zoneConfig name="Zone 1 Config 1">
<volumeGroups>
<group>
<device address="bus_101">
<context context="music"/>
***
</device>
</group>
</volumeGroups>
</zoneConfig>
</zoneConfigs>
</zone>
</zones>
To facilitate management of the audio configurations the car audio manager exposes APIs to manage the configurations:
- Query configurations available to a zone.
- Query currently set configuration for a zone.
- Switch to a different configuration.
A system UI app or service can use these API to manage the configuration for the audio zone as shown in Figure 4. The Query API exposes the two to the passenger. The user can select a different configuration by tapping a command for the desired configuration.
Figure 4. Dynamic zone configuration workflow.
Primary zone passenger audio cast
The primary zone passenger audio cast is a feature introduced in Android 14 to allow for passengers to cast their media audio in the primary zone. In this manner the passenger's media audio can be cast to the main cabin while the driver remains in full control.
The figure below shows a simplified version of the architecture for the primary zone passenger media audio cast.
Figure 5. Dynamic zone configuration workflow.
The image shows that the media output device for the driver is shared with the passenger, this only happens while the passenger is in cast to primary zone mode. The dynamic audio policy is also used to manage the audio routing for the driver but no changes are applied to the device affinities for the driver. For the passenger the list of output devices are changed as followed:
- Media output device for passenger is removed from list of devices
- Media output device for driver is added to list of devices
- Remaining output devices for passenger audio zones stay on list of devices
This new list of devices is assigned to the passenger by the
AudioPolicy#setUserIdDeviceAffinity API. The parameters passed to the API are
the list of devices and the passenger user ID. When the audio system's audio
policy service queries which audio mix is to be selected for a media track
associated with the passenger, the media audio mix associated with the primary
zone is selected.
A key requirement for primary zone audio cast is that the primary zone's media output device be isolated from other audio attribute usages. Otherwise, during construction of the audio mixes, other audio attributes are added to the mix. When the mix selection is performed by the audio system, all sounds attached to the mix are selected for playback in the main cabin.
Passenger zone audio mirror
The audio mirror feature enables passengers to share audio. The mirror feature duplicates audio data in each audio zone so that all passengers can listen to the same audio. In this case, the audio focus is shared with the passengers involved in the audio mirroring.
Audio mirror routing
A minimum of two passengers is needed to enable audio mirroring. As a result, an audio configuration with only two passenger audio zones would require one mirror output device. With the definition above, two concurrent mirroring sessions can be started.
The figure below shows a simplified diagram for the multi-zone audio mirroring
between two passengers. Audio from both passengers is routed to an audio mirror
device, bus_1000. The Audio HAL duplicates the signal to the source zones.
Figure 6. Dynamic zone configuration workflow.
This routing is enabled only when the passengers are in mirroring mode. If
not, the corresponding devices for the audio zone are assigned to passengers.
When mirroring is first enabled for a passenger, the
AudioPolicy#setUserIdDeviceAffinity API modifies the routing:
- Media output device for passenger is removed from list of devices.
- Mirror output device added to list of devices.
- Remaining output devices for passenger audio zone stay on list of devices.
With the list of devices, the API is called with the updated list of devices and the passenger's user ID. The following image provides a sequence diagram of the audio mirror workflow.
Figure 7. Audio mirror workflow.
In Figure 7, the car audio manager's APIs for managing the audio mirroring are
called from the Media System Service. Specifically, the API to enable audio
mirroring for User 1 and User 2, CarAudioManager#enableMirrorForAudioZones.
The car audio service configures the audio routing for user passengers as described above. Car audio service also sends a signal to the audio HAL to configure and duplicate the audio from the mirror device to the corresponding zones.
In the image above, the car audio service sends
mirroring_src=bus_1000;mirroring_dest=bus_10,bus_20
where,
bus_1000 is the source bus and bus_10 and bus_20 are the destination
buses.
Not shown in the sequence diagram is the signal sent via the
AudioManager#setParameters API, which reaches the HAL through the audio
service.
Upon disabling the audio mirror, the following signal is sent,
mirroring_src=bus_1000;mirroring=off. This signal can be used by the HAL to
disable audio duplication when audio mirroring is not enabled. To define audio
mirroring devices, the car audio configuration file contains a section named
mirroringDevices, as shown on the snippet below.
In this snippet, two mirroring devices are defined, bus_1000 and bus_2000,
so that four passengers can use audio mirroring.
<carAudioConfiguration version="3">
<mirroringDevices>
<mirroringDevice address="bus_1000"/>
<mirroringDevice address="bus_2000"/>
</mirroringDevices>
<zones>
....
</zones>
</carAudioConfiguration>