...
- everyone delivers a quick personal introduction
- Jimhyuk works for mobis technical center Europe (MTCE), he is an IVI expert
- Patrick works for mobis technical center America (MTCA)
- Piotr indicates he would like to have a less hardware aware Android
Review of the lost list of prioritarized topics
- list upated online, each contributor explains the rationale for setting the priority he chose
- 1- Networked Audio Devices: 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
- 2- Overall configuration management
- Piotr: there is no way to automatically validate the configuration
- Andrey: IMHO there is more important things to solve than the configuration
- 3- Common Audio HAL
Piotr: audio HAL is not so HW dependent because of tinyalsa, the porting the common audion HAL should be limited to tinyalsa
Andrey: I do not think whether we can make a common audio HAL, it would be great to have such a common HAL for using eAVB ?
Piotr: some hw vendors are working on it, must be feasible
Gunnar: this is about finding the common part, this is about avoiding duplicated effort to provide the same functionalities, this about reducing the amount of effort for each vendor to implement the HAL
- 4- Audio Data Transfer
Suhasini (not captured)
Piotr; utilizing a DSP is very hw specific, this is why I put it a low priority, however it is important, it should be high priority
Gunnar: this is about finding the right abstraction
Piotr: we need to talk about interfaces / abstraction to create audio effects
- 5- Equalization
- all agree it is high priority to have a way to control the equalization
- 6- Audio calibration
- Suhasini; audio calibration sounds to me like controlling global effects, not as big a problem as others
- Piotr: agreed, could be covered by the same interfaces, there is a need for the a generic interface
- 7- Controlling audio effects
- the above 3 items could be covered by the same interfaces
8- Latencies
Suhasini: for Analog Devices, latencies are important because we have a lot of time sensitive applications, currently we are doing these on the DSP, we would be interested in moving some of them on the Android system
Piotr: IMHO the latencies question is pretty hw specific, it cannot be solved in a general way, this is rather Google responsibility with their framework
Piotr: another problem is shared audio on a virtualized platform, not sure we can solve this problem in a joint effort
Gunnar: in the GENIVI Hypervisors (HV) project, Opensynergy is behind the proposal for a set of standard interfaces for the audio platform, we could dig into it if there is an interest in the Audio HAL group
/TODO/ Gunnar organize a presentation of the work done by the HV project on the standard interfaces for the audio platform
Andrey: we encountered a problem with latencies when we switched to hypervisord, actually we had problems with latencies AND scheduling
Gunnar: it is a difficult challenge, agreed
- 9- Multiple audio channels
- Bosch indicated their challenge is to adapt the AA framework to their HW I/O, e.g. they have 4 audio channels while they need to present them as 2 audio channels to AA
Piotr: it is hard for me to judge because it is very specific, my claim is that it can be solved with AA
Andrey: I do not know it was feasible
Philippe: this needs further investigation
10- Early audio for RVC
Andrey: early audio RVC will be rather handled by the HV or RTOS, because there are safety requirements which cannot be achieved by AA
Suhasini: what is the audio application for RVC ?
Andrey: (not captured)
Stephen: there might be one opportunity for standardization, some people manage the early audio on RTOS and then switch over to AA framework
Piotr: one possibility is to have 2 audio HALs, one "simple" audio HAL for early audio and one full feature audio HAL
Philippe: iy would be good to look at a standardized way of switching modes
Andrey: we still have the safety requirements for this
- 11- Source Management
- Multi‐source multi‐sink, etc.
- Piotr: this is in the framework, it maybe not be worth looking at it as first priority, this is why I put a low
- 12- Audio focus
- Andrey: it would be great to get applications on AA to request audio focus (not optional audio focus), usually automotive use cases have a limited
number of sound applications
Patrick: at Mobis we have our own sound manager and pass it to AA, adding a little man between the sound applications and AA works well
Patrick : I do not know much effort we put in this tool though
Gunnar: IMHO the concepts supported by the GENIVI audio manager component might be relevant for this issue
/TODO/ Gunnar contact the "right" person (i.e. who knows the GENIVI audio manager component) and organize a presentation of the concepts supported
- review of other topics will continue next week
...