...
- 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 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 ?
- Piotr: there is no limitation AFAIK
- Nadim: there is a table (as Piotr said it's static) that determines what audio can be mixed https://source.android.com/devices/automotive/audio/multi_zone/audio-focus
- 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
- 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 history 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 about an experiment 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 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 I think we should think determine 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 androidAndroid, this is how it was designed
- Specifically in Andoird 10 Android10 they dropped Auto ducking because they reached a the conclusion that they cannot control all sources
- Audio zones is limited to AA but we can stil luse still use external audio management (https://source.android.com/devices/automotive/audio#external-streams)
- Philippe: how to do we manage Safety critical applications (ADAS for example) ?
- Piotr: this can be handled by the external management that Bartosz mentioned
- Gunnar: let's think of a multizone concept outside of AA because:
...
- 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 (all times are CET)
- 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
...