Page History

List of prioritized topics for the Audio HAL

Multiple-zone audio namangement - reference system design

Next Meeting - Thursday 19 March - 11:30am CET

...

• 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

  • manages all

  sivks

  • sinks and sources

  :

  • , i.e. all audio management

  from

  • is inside AA

  • 2

  the other extreme scenarri is (not captured): management from AA, control outside AA
  simple AA is

  • 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: Philippe: the objective of the poc is to validate our design , supporting and check it supports the required flexibilty

• Wassim; : scenario 2 control can be in a different software partition or soc SoC or an external ECU

• Philippe: we 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 and agree on a reference system designPiotr has alrzady a presentation assigned

• 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

• discussion on how to jump start on the reference system design

• /TODO/ Wassim to initiate a wiki page describing the block-diagram of a possible reference system design

Thursday 12 March - 11:30am CET

...