...
- 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 history many systems (like MOST based for example) are outside of AA and the Infotainment Head Unit, getting the raw data streams out and they would rely on local DSP or amplifier to tune or do an effect
- (alternatively, if you wish) think of it as just a thought about an experiment to see what problems we might encounter to understand better the concept
- is → is there any limitation in the AA model? let's discover it
- (Question: But why not just assume AA to be in charge of all the audio management?)
- Gunnar: Another reason is the complexity of real car development. Consider car models with different (Infotainment) variants where the one variant might not What about systems with different variants where the cheap variants don't have AA but are based on a different OS? (You may then be forced to use solutions that work across all those variations of systems)
- 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 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 Android, this is how it was designed
- Specifically in Android10 they dropped Auto ducking because they reached the conclusion that they cannot control all sources
- Audio zones is limited to AA but we can still use external audio management (https://source.android.com/devices/automotive/audio#external-streams)
- Philippe: how 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:
...