Dial-in by your location
Meeting ID: 470113570
Find your local number: https://zoom.us/u/aCAyOAcT6 |
Agenda
Agenda items (to be prioritized at the beginning of the call)
Participants
Agenda
Minutes
GENIVI Audio Manager Q&A
Henric: I looked at the document, the AA framework also does audio management, how AM & AA both fit together ?
Gunnar: the main idea was to learn from the AM which solved this issue in existing production systems, the goal is not likley to reuse the AM code directly
Wassim: we have already systems using AM, if AA were used because it can meet the AM specifications, this would be fine
Nadim: I looked also at the document, what the AM is all about ? why is the rationale for using the AM ?
Gunnar: we said that reading the AM specifications is to learn about the concept and possibly reuse the concept
Wassim: we are doing automotive, does everyone have an automotive focus in the team ?
Gunnar: yes
Wassim: we need to look at system level, we can have a head unit, rsa, headphones for passengers,
Wassim: while each vendor develops their own ECU, the problem for the OEM to set/control/configure all the parameters in a centralized way, we need to control things in a centralized way,
Wassim: AM makes only the connection between sources and sinks and relies on other libraries to support the audio stream communications
AA offers the connection to Alsa at a device level, but fails to handle the connections at system level
this is the interested part of the discussion we should have: the handling of multiple connections is to be handle in the vendor partition (Audio HAL)
Wassim: I am interested in vendor agnostic (and OEM agnostic) solutions to solve the handle of multiple connections
Nadim: we would recommend to reuse the AM then
Wassim: you do not need an AM everywhere in the system, you need however a routing adapter in every ECU of the system
discussion on the architectural design of the AM (AM daemon, plugins)
Gunnar; the AM daemon can be used by everyone *unchanged*, the plugins have to be adapted to a given project details
Wassim: if you have multiple (audio) domains, you might also vendor specific buses for each domain, so you will need gateways to convert from one domain to another
Wassim: you informed the AM that you have two domains for instance and the AM will know about the routing to provide
Gunnar: if we look at the AA system, do I simplify too much if I say we want the AA system to produce all streams, controlling the mixing and priorities ? (to be re-captured, Gunnar Andersson please update)
Wassim: let me give an example use case
I have one button somewhere and I want to select the AA radio and route the audio stream to the device where I touched the button
Wassim: our goal is to give the capability of having all devices on the same SoC and having the external amplifiers in another location
Wassim: it would be nice also to have classes of sources (entertainement, announcements, etc.)
Gunnar: what is Tieto thought on this ?
Piotr: there are classes in AA, there is a hardcoded matrix to describe them since AOSP 10
AA exposes those to 3rd party applications, there is a framework layer and the HAL layer, are we fine with the features supported by the framework layer ?
discussion on how to use the framework features (audio flinger for instance)
is the framework functionality enough for implement what we need in the car ?
Gunnar: IMHO there are too much features in the AA framework (to be re-captured, Gunnar Andersson please update)
discussion on what we should standardized outside of AA
Wassim: could we iidentify and name the 2 following scenarii ?
1 android manages all sinks and sources, i.e. all audio management is inside AA
2 all audio management is outside AA, this is the so-called simple scenario where the audio management is done externally
Nadim: what is the expectation for the poc ?
Philippe: the objective of the poc is to validate our design and check it supports the required flexibilty
Wassim: scenario 2 control can be in a different software partition or SoC or an external ECU
Philippe: we need to agree on a reference system design to implement the poc use cases
/TODO/ all participants to produce their own system design from which we will identify commonalities and agree on a reference system design
Gunnar: Piotr was already assigned a presentation on multi-zone management (for next week)
Nadim needs to understand better the problem
Gunnar: how to manage an external amplifier with AA is a use case by itself
/TODO/ Wassim to initiate a wiki page describing the block-diagram of a possible reference system design
Participants
Agenda
Minutes
GENIVI Audio Manager
Nadim: stiil need more time
Piotr : still on my todo list
Suhasini: went to the architecture overview
Henric : on my todo list
Gunnar: if this is the right way of doing ?
Nadim: Philippe is right, it should be on the top of the list
Gunnar: the AM is how to design an audio system which is flexible
Wassim: do we agree we all need a vendor partition distinct and beyond from Android Automotive ?
PoC design
Project workplan
Participants
Agenda
Minutes
Roundtable
GENIVI Audio Manager
recap on the decision made by the team last week to get awareness on the GENIVI Audio Manager
Gunnar: the code might not be reusable as such in an Android Autmotive context, but it is worth understanding the archictectural design of the Audio Manager
Gunnar: Android is lacking the flexibilty audio systems have in a car, this project intends to enhance this
Wassim: there are deployed systems using the linux based GENIVI Audio Manager or using Android Automotive, who should take care of the audio management in the Android context ?
Gunnar: there 2 tracks one is to find out the audio management requirements in the Android Automotive context, track #2 is to achieve this with the appropriate technologies, we need to decide first what we want
Wassim: we need to define the common problem statement the Audio HAL wants to solve
Discussion on the Audio HAL project workplan
Participants
Agenda
Minutes
Networked audio devices
Gunnar: Le'ts start with the networked audio devices overview. It can be good input information before discussing PoC details
Suhasini presents her slide deck (link)
Wassim: When you say streams, (and the red lines in the picture), what does it mean?
Suhasini: It represents a network connection of some type (any type). Streams, I mean an audio stream logically from one device to another here. On the next slide there is a mapping shown.
... mapping slide
... Automotive Audio Bus (A2B) slide.
A2B is an example of single master, multiple slaves setup.
It is routed according to your configuration.
You can for example configure that mic input must go to head unit. Protocol takes care of it according to configuration.
Problem: Physically speaking the head unit is connected to only one device. The system views it as a single device.
On the logical picture, one stream is connecting to more than one receiver. Viewing as a separate device is useful but...
Android 10 features has Audio Device Out but, but it's not clear if we can address (receiving nodes) as we want.
Wassim: One device visible but many logical channels...
Suhasini: Problem 2 could be diagnostics support. Checking if the node is in an OK state...
Control path should be able to support more than volume. E.g. a series of diagnostic routines that can be initiated.
ALSA has minimal support also for this.
Wassim: ALSA supports well the (audio) data flow but not control. GENIVI audio manager has the primary purpose to define such interfaces. (It is not handling the audio stream directly).
The drivers (from silicon vendor) might still be implement the control function itself.
Wassim: The vendor needs to provide a HAL for those control functions. If Android defined the interface, this might be implemented.
Summary: View each device stream separately inside Android.
Discussion yields that we should perhaps handle each stream separately, in addition to devices. (sink and source abstraction)
Agree that each single stream could have types (mono, stereo, multi-channel) but we don't expect to need to handle reconfigure channels.
Gunnar: In addition to differentiating the individual receiving devices I expect we need to consider that one or several streams per device?
... how to implement additional features ...
Wassim: GAM for example has a generic support for "Properties" from user to sink, and "Notifications" from sink to user.
Gunnar: Note: "user" here means the controlling software, either the application or the main system HMI that is defining the behavior we want to have from the audio system.
Wassim agrees.
Discussion on other needed control interfaces... example: firmware update?
More discussion..,
Suhasini: In order to transfer a certain stream e.g. phone input to some output, this in the end needs to be configured in hardware...
Initial configuration will be created by the vendor, but some kind of interaction with the driver is needed.
Wassim: Look at open documentation to AudioManager. The routing plugin abstracts the logic of this. The implementation is doing the connection between hardware specifics and the generic interface.
I have seen that Android also allows some kind of custom bus implementation, but have not yet seen if this solves it.
Bartosz (Harman) - short introduction. Android engineer, not specifically focused on audio however. Based in Poland.
Action (all): Read up on the architecture and interfaces of the GENIVI Audio Manager, since it was designed to make a framework for exactly this. Docs: https://genivi.github.io/AudioManager/
The ideas / design / APIs should be reusable. Possibly some code also, eventually.
Stephen: Are those docs also covering plugins?
Gunnar: To further understand plugins, try looking at code of the plugins: https://github.com/GENIVI/AudioManagerPlugins (The code of the AM daemon is at https://github.com/GENIVI/AudioManager/ )
Stephen finds another slide deck describing routing-adapter.
PoC planning
We had 2 main topics: Global Effects API and more flexible audio channel routing.
Gunnar: OK so the discussion we had before led forward in the audio channel routing topic. What about Global Effects?
Bartosz (Tieto) reports that the plans for the next Android version include new interfaces that seem likely to solve the global-effects problem.
It is possible therefore that we do not need to work out solutions for global effects: LINK 1
, LINK 2, LINK 3
Adjourned at 12:25.
Participants
Agenda
Minutes
Overview of last week's F2F outcome
Nadim: Bartoz, Gunnar and Piotr wanted to know about which technologies Analog Devices has in mind for the networking of audio devices, this is why AVB popped up
Call for participation
Suhasini: /TODO/ in 2-week time, will give an overview and a problem statement for the networking of audio devices
Audi HAL call schedule
Participants
Minutes
upcoming F2F meeting
AOB
Participants
Minutes
upcoming F2F meeting for the Vehicle HAL project
Review of the list of prioritarized topics (continuation)
13- BT handsfree
Suhasini: it is rather a question of multisource management
Andrey: would agree it is related to multisource management
Gunnar: on the mobile phone, the BT role is the server role, the car is more the handsfree role
Andrey: we need to clarify the automotive use cases
the group should work on use cases but there are more fundamental questions to be solved on multi source management
14- Android does not implement all features required by customer.
Andrey: this is about multisource management, support of external devices, limited number of priorities, etc. the various bullet points can be distributed over the table
/TODO/ Andrey distribute the bullet points among the table
Piotr: what are the priorities you are talking about ?
Andrey: these are the priorities related to phone calls, I will clarify this when I do the split (phone calls vs. not phone calls)
15- Android Audio subsystem is developed only for infotainment purposes. Safety-related features need to be implemented in another RTOS
Andrey: thinks the safety-related audio features are not in the scope of this group
Piotr: we need to keep in mind that there is a higher priority audio functionnality in the system
Gunnar: it might be worth discussing how AA can use external components that manage the higher priority audio functionnality, these are system-level considerations
/TODO/ Gunnar add HERE what was discussed in this call about the system level architecture Thanks
Gunnar: do we look for solutions on AA side first or do we look also at the general system design for audio ? my recommendation is to start something concrete at the design level
16- Android way of extending its functionality is developing vendor extensions without modification of the framework
Piotr: we need to avoid changing the framework because there is a lot of manual work necessary to track the changes that need to be taken into account
Andrey: agreed
Andrey: we have a mechanism in Harman to follow up the changes in AOSP
Gunnar: we need to start the design work asap and as a general principle we do not change the framework
17- Google is still very “hand wavy” about solution
Gunnar: WR has a lot of work to implement the audio HAL by themselves
Piotr: people look at the code of android directly, I would like to get some tooling to cope with the fact the doc will not be provided by Google anyway
Piotr: tool can take care of the configuration setting, helping with work we do currently manually
Andrey: we need to adapt to the Google way, we cannot change this
Piotr: we can translate HIDL to Franca and provide a more flexible way of implementing things
Andrey: we are considering similar ideas within Harman
Gunnar: agreed, it is part of the discussion on how to use a common interface in multiple systems (with the remote interfaces, not only on AA), something like CommonAPI, there is a generic discussion to have there
18- Genivi ?
Gunnar: in my opinion this is a question about the role of GENIVI, we need to think about what could be the outcome of the group, as I said before, the question is rather to find solutions, it can be anything from a formal specification, to guidelines and even code
list of prioritarized topics
Next call
Participants
Minutes
Roundtable
Review of the list of prioritarized topics
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
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
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
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. Can the methods on Android side by standardised? This also applies to other 'early' features such as video for reversing camera.
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
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
F2F opportunity in early Q1/2020
Next call
Participants
Minutes
Introduction
Configuration & Common Audio HAL
Next call
F2F meeting opportunity
Participants
Minutes
Introduction
Philippe welcomes participants and details the agenda
Philippe recommends the review of the presentations delivered by Tieto and Windriver at the tech summit in Detroit where they presented their return of experience on Android Automotive, in particular on Audio HAL
please look here, search for "return of experience"
Introduction to Audio HAL
Gathering of list of topics for the Audio HAL project
Adjourned: 18:20 CET
Participants
Minutes
Next steps
Next call