Versions Compared

Old Version 53

changes.mady.by.user Philippe Robin

Saved on

compared with

New Version 54

changes.mady.by.user Unknown User (niskandar)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added minutes

...

  • how to control multizone from the system service
  • reference system design
  • AOB

Minutes of AUDIO_HAL_CW13

how to control multizone from the system service

  • tietoEVRY shows slide deck presenting the results of the PoC experimentation they made
  • under the hood slide: this a long away to go to achieve a simple functionality
  • useful links for understanding audio zone management in Android Automotive
  • discussion on the poc outcome slides follows
    • Nadim: you cannot change zone w/o stopping the playback, that's a negative or missing point
    • the use case discussed in the previous call (push a button and change the audio focus) is discussed again
    • Piotr: the approach was not to change the AA framework to implement this PoC
    • Piotr: I would recommend to build a new functionality based on existing functionalities, i.e. like the development of a get UID of active tracks, create such a service would allow the driver to manipulate the UI  for redirecting applications to a given audio zone
    • Wassim: are these zones like "play in the front or in the back", or "play on the main speakers or on the headphones
    • Piotr: for each zone, the context is defined
    • Wassim: how does the balance function interact with the multizone management ?
    • Suhasini: are the zones more logical than physical ?
    • Piotr: Google says a zone is a collection of devices (look at the definition at the beginning of the slide deck)
    • Wassim: the device can have a mapping of the different speakers, this is different from a setting like the balance
    • Wassim; do we have a limit of the number of apps that can be mixed ?
    • Wassim:  let us assume the actual hw have a limitation on the number of audio channels that can be mixed Wassim:  let us assume the actual hw have a limitation on the number of audio channels that can be mixed at the same time
    • Bartozs: when the limit is encountered, the audio HAL should report an error which is communicated back to AA
    • Wassim; the limitation does not come from AA, but the error can be reported (general error handling in AA)
    • Piotr: the audio focus is separate for each audio zone
  • random thoughts
    • discussion on missing functionalities in AA
    • Wassim: IMHO android does not to be aware there is an outside device controlling the audio (capture is TBC)
    • (Nadim takes over notes taking) <== Unknown User (niskandar) /TODO/ please insert your notes here or in another wiki page, thanks)

reference system design

  • Wassim: last week, we discussed whether the (audio) control should be inside vs outside AA, I have prepared a short slide deck on this
  • Philippe: reminds the team about the handling of safety-related audio notifications (from ADAS systems for instance); this calls for having some audio management outside of AA
  • Wassim: we need to revisit the discussion we had between the 2 extreme approaches of having all audio management inside AA and having all audio management outside AA
  • discussion carried over to next week's call, Wassim will present his slide deck

GENIVI Spring Virtual Technical Summit

...

    • Nadim: what is the A2B in the presentation?
      • Piotr: AA is missing support for A2B
      • Suhasini: yes we know about this.
  • random thoughts
    • Gunnar: let's think of a multizone concept outside of AA because:
      • from hustory many systems (like MOST) are outside of AA and they would rely on local DSP or amplifier to tune or do an effect
      • just a thought experiemnt to see what problems we might encounter to understand better the concept
      • is there any limitation in the AA model? let's discover it
      • What about systems with different variants where the cheap variants don't have AA but are based on a different OS?
    • Henric: in Audio hal there are options to access input/output streams this can be useful
      • Gunnar: if we are under the Audio HAL we have the possibility to do whatever we want with the streams
    • Wassim: so this gets us back to the main topic of thinking about managing the audio with AA in control and with AA not in control
    • Wassim: we need to think more about which model is better suited for our cases
      • Nadim: I think it's better to follow the AA in control model because it might be cheaper in the long run and because it includes a lot flexibility
    • Wassim: how much flexibility though? does it cover all of our cases? what are our cases actually? maybe we can gather the cases for next week
    • Piotr: what direction should we continue with the POC?
      • Wassim: i think we should think what model is better: AA in or not in control
      • Piotr: so the AA not in control would be some sort of a Framework (FW) service that is injecting audio data to AA
    • Bartosz: here are some inputs from my side:
      • AA is expecting that some sources are not handled by android, this is how it was designed
      • Specifically in Andoird 10 they dropped Auto ducking because they reached a conclusion that they cannot control all sources
      • Audio zones is limited to AA but we can stil luse external audio management (https://source.android.com/devices/automotive/audio#external-streams)
    • Philippe: how to we manage Safety critical applications (ADAS for example)
      • Piotr: this can be handled by the external management that Bartosz mentioned

GENIVI Spring Virtual Technical Summit

  • the virtual tech summit will be organized as half-a-day workshops scheduled to be either at US-friendly time or Asia-friendly depending the expected geo-location of the main participants
    • Tuesday 12 May afternoon (US friendly):  president's keynote and state of the union followed by a couple of sessions about "looking forward" topics
    • Wednesday 13 May afternoon (US friendly): AASIG VHAL engineering workshop (3 hours)
    • Thursday 14 May morning (Asia friendly): AASIG Audio HAL engineering workshop (3 hours)
    • Thusday 14 May afternoon (US friendly) : Cloud & Connected Services engineering workshop (3 hours)
    • this is still TBC but please make a note in your calendar

Decisions taken in AUDIO_HAL_CW13

  • Agenda for AUDIO_HAL_CW14:
    • Slides from Wassim about the two models inside and outside of AA
    • discussion of the cases/features that we are trying to solve
    • checking the Audio Manager to decide whether or not it needs an update
  •  @all: Think and prepare diagrams of how you see the models of AA in control of the audio management and AA not in control of the audio management
  •  @all: Check what features and what cases do we have in order to validate both models
  •  @all: Prepare any questions about the Genivi Audio manager, mainly think if it's worth it to update it. Is AA audio manager missing some features?
  •  Unknown User (niskandar)focus on taking minutes of meeting

...

Thursday 19 March - 11:30am CET

...