You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

WARNING

WORK IN PROGRESS

Topics / Priority (high, medium, low)

Category

(all TBC)

SuhasiniAndreyStefan KPiotr

Wassim

Alexander

Gunnar

we have a portfolio of audio processors and an automotive audio bus to distribute audio within the car, we want to configure our proprietary audio bus SW stack to use it with AA as we did for Linux

Configuration
Low






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

Configuration
Low



configuration management component for TinyALSA

Configuration
Medium



Support for the configuration of networked audio devices. Currently Android can view it only as a single device/sound card. An audio network in car might have multiple devices that needs to be controlled by the Android OS.

Configuration
High



Configuration Challenge (look at slide 12 of tech summit deck)Configuration
Low



Common Audio HAL (look at slides 15-20 of tech summit deck),Configuration, Common Audio HAL

Medium



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

Performance
Low



Latencies

Performance
High



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)Common HAL
High



there is no Audio calibration interface

Common HAL
Medium



there is a need for a generic interface for controlling audio effects on HAL level, global effects are designed for input streams but control over them is limited by interface

Common HAL
High



I/O for our Bosch HW, the challenge is to adapt the AA framework to our HW, which has for instance 4 audio channels while we need to present them as 2 audio channels to AACommon HAL
High



early audio for RVC (Rear View Camera) or other services

Common HAL
Low



Audio data transfer / streaming to a co-processor for post processing of audio from the HAL/other Android layers

Common HAL
High



  • Multi‐source multi‐sink
  • Stream types – not audio zones
  • Still limited to one sink
Multi-Source Management
High



Audio Focus doesn't forbid to interrupt Audio, Android 10 provides additional interface for Automotive to solve this problem

Multi-Source Management
Medium



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 lineMulti-Source Management
Medium



Android does not implement all features required by customer.

  • Audio focus can be lost at any time
  • Limited number of sources
  • Limited number of priorities -2
  • No easy way to support external amplifiers
  • No priorities of phone call types.
Multi-Source Management
High



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
Multi-OS Integration
Medium



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
Extensions
Medium



  • Google is still very “hand wavy” about solution

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

Extensions
Low



  • Last two‐miles left to IVI developer

  • (Android P improvements?) …more churn?

  • Genivi?

Extensions







  • No labels