...
- Discussion on PoCs scope
- Networked audio devices
- PoCs architectural design
- backlog update
- AOB
Thursday 27 February - 11:30am CET
Networked audio devices
Gunnar: Le'ts start with the networked audio devices overview. It can be good input information before discussing PoC details
Suhasini presents her slide deck (link TODO)
Wassim: When you say streams, (and the red lines in the picture), what does it mean?
Suhasini: It represents a network connection of some type (any type). Streams, I mean an audio stream logically from one device to another here. On the next slide there is a mapping shown.
... mapping slide
... Automotive Audio Bus (A2B) slide.
A2B is an example of single master, multiple slaves setup.
It is routed according to your configuration.
You can for example configure that mic input must go to head unit. Protocol takes care of it according to configuration.
Problem: Physically speaking the head unit is connected to only one device. The system views it as a single device.
On the logical picture, one stream is connecting to more than one receiver. Viewing as a separate device is useful but...
Android 10 features has Audio Device Out but, but it's not clear if we can address (receiving nodes) as we want.
Wassim: One device visible but many logical channels...
Suhasini: Problem 2 could be diagnostics support. Checking if the node is in an OK state...
Control path should be able to support more than volume. E.g. a series of diagnostic routines that can be initiated.
ALSA has minimal support also for this.
Wassim: ALSA supports well the (audio) data flow but not control. GENIVI audio manager has the primary purpose to define such interfaces. (It is not handling the audio stream directly).
The drivers (from silicon vendor) might still be implement the control function itself.
Wassim: The vendor needs to provide a HAL for those control functions. If Android defined the interface, this might be implemented.
Summary: View each device stream separately inside Android.
Discussion yields that we should perhaps handle each stream separately, in addition to devices. (sink and source abstraction)
Agree that each single stream could have types (mono, stereo, multi-channel) but we don't expect to need to handle reconfigure channels.
Gunnar: In addition to differentiating the individual receiving devices I expect we need to consider that one or several streams per device?
... how to implement additional features ...
Wassim: GAM for example has a generic support for "Properties" from user to sink, and "Notifications" from sink to user.
Gunnar: Note: "user" here means the controlling software, either the application or the main system HMI that is defining the behavior we want to have from the audio system.
Wassim agrees.
Discussion on other needed control interfaces... example: firmware update?
More discussion..,
Suhasini: In order to transfer a certain stream e.g. phone input to some output, this in the end needs to be configured in hardware...
Initial configuration will be created by the vendor, but some kind of interaction with the driver is needed.
Wassim: Look at open documentation to AudioManager. The routing plugin abstracts the logic of this. The implementation is doing the connection between hardware specifics and the generic interface.
I have seen that Android also allows some kind of custom bus implementation, but have not yet seen if this solves it.
Bartosz (Harman) - short introduction. Android engineer, not specifically focused on audio however. Based in Poland.
Action (all): Read up on the architecture and interfaces of the GENIVI Audio Manager, since it was designed to make a framework for exactly this. Docs: https://genivi.github.io/AudioManager/
The ideas / design / APIs should be reusable. Possibly some code also, eventually.
Stephen: Are those docs also covering plugins?
Gunnar: To further understand plugins, try looking at code of the plugins: https://github.com/GENIVI/AudioManagerPlugins (The code of the AM daemon is at https://github.com/GENIVI/AudioManager/ )
Stephen finds another slide deck describing routing-adapter.
PoC planning
We had 2 main topics: Global Effects API and more flexible audio channel routing.
Gunnar: OK so the discussion we had before led forward in the audio channel routing topic. What about Global Effects?
Bartosz (Tieto) reports that the plans for the next Android version include new interfaces that seem likely to solve the global-effects problem.
It is possible therefore that we do not need to work out solutions for global effects: LINK 1
, LINK 2, LINK 3
Adjourned at 12:25.
Thursday 13 February - 11:30am CET
...