...
- GENIVI Audio Manager Q&A
- how to control multizone from the system service
- Audio HAL project workplan
- AOB
Thursday 19 March - 11:30am CET
Participants
- nadim, henric, piotr, wassim, ruslan, suhasini, gunnar, philippe, stephen
- apologies: bartosz bialek
Agenda
- GENIVI Audio Manager Q&A
- how to control multizone from the system service (skipped, scheduled for next week)
- Audio HAL project workplan
- AOB
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 manage all sivks and sources: audio management from AA
2 the other extreme scenarri is (not captured): management from AA, control outside AA
simple AA is where the audio management is done externallyNadim: what is the expectation for the poc ?
>>>>>>>>>>>>>>>>>>>>>>>>
philippe: to validate our design, supporting the required flexibilty
Wassim; scenario 2 control can be in a different partition or soc or an external ECU
Philippe: need to agree on a reference system design to implement the poc use cases
block diagram
/TODO/ all participants to produce their own system design from which we will identify commonalities
Piotr has alrzady a presentation assigned
Nadim needs to understand better the problemhow to manage an external amplifier with AA is a use case by itself
/TODO/ Wassim to initiate a wiki page describing the block-diagram
Thursday 12 March - 11:30am CET
Participants
...