...
- how to control multizone from the system service
- reference system design
- Audio HAL project workplan
- AOB
Thursday 26 March - 11:30am CET
Participants
- nadim, henric, bartosz, piotr, lukasz, suhasini, wassim, philippe, gunnar
Agenda
- how to control multizone from the system service
- reference system design
- AOB
Minutes
how to control multizone from the system service
- tietoEVRY shows slide deck presenting the results of the PoC experimentation they made (Piotr Krawczyk please upload the slide deck, thanks)
- 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 follows
- Nadim: you cannot change zone w/o stopping the playback
- 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 ?
- Piotr: there is no limitation AFAIK
- 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) 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
- 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
Thursday 19 March - 11:30am CET
Participants
...