Attendees: Takashi Iwai, Mark Brown, Vinod Koul, Patrick Lai, Lars-Peter Clausen, Eric Laurent, David Henningsson, Tanu Kaskinen, Arun Raghavan, Paul Handrigan, Daniel Mack, Dylan Reid, Charles Keepax, Nariman Poushin, Peter Meerwald, Alexander Patrakov, Hui Wang, Tim Cussins, Nick Stoughton
Topic: ASoC componentization
Motivation - hardware is becoming more complex as CPU and CODEC functionality are overlapping. Codec now has DSP. DSP on CPU need DAPM and IO. Current ASoC APIs are based on clearly distinguished component type, platform, CPU, CODEC. It makes difficult to support complex configuration such as CPU -> CODEC -> CODEC or DSP with DAC, ADC, SRC
Points discussed - Componentization is coming on V 3.18.
- Lars-Peter is cleaning up suspend/resume logic in ASoC framework as conflicting with individual driver suspend/resume. Goal is to move toward bus suspend/resume
- Grand scheme is to treat hardware module as component instead of clearly distinguish component type(platform/cpu/codec). Russel King introduced component framework recently - one master with many slave components. ASoC could adopt component framework. Sound card would be the master while individual drivers register slave components. Moving to use component framework would help unbinding of drivers cleanly as well.
- Discuss possible phasing out/refactor DPCM, DAI-LINK and add support to DAPM for PCM configuration propagation.
Topic: Dynamic FW framework
Motivation: It is very common for SoC/CODEC vendors putting DSP onto their hardware. Topology/functionality can change based on DSP image being loaded. Dynamic FW framework is designed to address the need to run-time create DSP topology graph without hard coding into the driver
- For DSP with large memory case, swapping DSP image at run-time might not be a concern so firmware download can happen once after boot up but CODEC DSP tend to be memory constraint. Run-time swapping requiring deregister of existing controls and register with new one. ALSA framework does not have good support for this requirement currently.
- DFW tool allows each solution vendor to develop its own plug-in and can convert static description to DFW binary format. Through this way, solution vendor can specify its own data and associate with ASoC component such as DAPM widget.
Topic: Mapping channels through DAI links in ASoC
Motivation: Currently, it is difficult to track how each channel get propagated from one component to another i.e 8 channel streams from CPU to CODECs with stereo channels in TDM interface
- Consensus that there is value to track the channel mapping - Possible solution is to create widget per channel of PCM object
Topic: ALSA test
- Discussed test ALSA core framework on virtual platform and patch submission should go through testing. For embedded system, the benefit may not be significant as bug tend to show up during use case transition
- David demonstrated HDA CODEC test. Perhaps, this test can be leveraged for ALSA core test framework
- There is no ALSA compliance test right now. There is small tool called alsa-time-test which could potentially be part of ALSA test suite. Another way to validate conformance is to run PulseAudio as PulseAudio exercises a lot of alsa-lib API
- Vinod suggested a test framework Liam has been developing, to compare the sign wave form with the captured one. Contribution is welcome and can be merged to any public repo. In addition, for *any* other test programs or metrics, contribution is welcomed.
Topic: ALSA documentation
- For mixer control related query, Documentation/sound/alsa/ControlNames.txt in kernel tree is a good resource to read
- Each kernel function can have a Javadoc style comment. This can be formated through DocBook directory in kernel tree as PDF or HTML (or anything else). So, from now on, the javadoc style comment is mandatory for each patch including exported symbols.
- the root DocBook template file is missing for ASoC. Presentation given by Mark in ELC few years back could be a good supplement for someone to get a quick intro to develop drivers to plug into ASoC framework
Topic: ALSA control names
- Even though in embedded world, SoC architecture from different vendors are not so consistent enough to come up with common name. There is still value to come up with standard name for different types of controls such as Volume, Ramp up/down time (in unit of DB per ms or sample count)
- Media controller discussion came up again as it can be solution to help user-space recognize mixer control for the topology
- General consensus is that each vendor should have control definition document to describe what each control do
- As part of user case transition, user-space often execute mute as well. Instead of ASoC framework handles digital mute as part of startup/shutdown sequence, let user-space have the control through mixer control command.
- Suggest to have volume, mute control per PCM object which takes the same approach as channel MAP API by exposing mixer control with name "<pcm device id> volume"
Topic: ALSA code removal
- Can OSS be removed? Anyone is still using OSS? Perhaps, OSS emulation can be done in user-space
- Add warning to notify people to contact usage of APIs to prevent deprecation
- Discuss removal of old driver but does not look safe to remove
- Suggestion to remove ADPCM support in ALSA core framework
- Removal in alsa-library: aserver, shm, and share plugins were discussed. The decision seems to be putting them under a ./configure switch now and remove later
Topic: DSP effect library/more DSP support
- For DSP effect, Intel goes through mixer control approach which controls are defined in the dynamic firmware. It is not clear how Android effect would be associate stream to corresponding mixer controls for the DSP effect
- Discuss couple issues when dealing with DSP architecture. These problems surfaces on PulseAudio 1. DSP DMA data as soon as it can put into its internal memory. Hence, hw_ptr does not reflect actual consumption point in DSP. This causes rewinding logic not function properly. It would be ideal if ALSA could allow driver expose granularity of hardware pointer
2. DSP continuous latency can vary. ALSA should have mechanism to allow driver expose latency information to user-space
Topic: consolidate jack report mechanism
Currently, there are K-control, input event, extcon mechanism to report headset jack events. Intel would like to see k-control as final solution in order to align with DSP notification through k-control Discussed to consolidate into one mechanism. One proposal from Mark is making a common in-kernel framework which all driver would use this jack framework, the framework would in turn expose this jack through different user-space interfaces depending on kernel configuration
Topic: Convergence of single configuration file format UCM vs mixer_path
Single format would make vendors who supports both UCM and mixer_path systems life easier. PulseAudio extract use cases list from UCM while mixer_path does not have such support yet.
Action item: Arun to look into the convergence effort
Topic: scheduled trigger start of PCM
- Nick to submit snd_pcm_start_at() patch. The change is software based solution but margin of error is acceptable for the use case in mind
- Brought up the use case which time stamp is sent along with every buffer so DSP knows to drop when the buffer is given pass the deadline.
Topic: ACPI
Intel is moving system-level device configuration file toward ACPI. Device specific data(_DSD) section defined in ACPI 5.1 specification allows device vendor to pass device specific data. (i.e CODEC device data).
Topic: synchronization of HDMI/USB hot-plug and configuration events
- Instead of waiting for USB hotplug event, Android should wait for udev event to notify new USB sound card is created - Discuss making HDMI a separate sound card. However, HDMI could simply be another routing path in a sound card for embedded architecture.
- Suggest to return error when reading EDID info is HDMI is not ready
Topic: Sharing hardware component between ALSA framework and other drivers
- When hot word is detected, go through DAPM to enable mic path.
Topic: Rewindng in ALSA PCM plugins
1. Discussion of the method to calculate the amount of samples that should not be rewound over after the hardware pointer. Result: the audience demonstrated general understanding of the issue. Lars suggested having two hardware pointers, because there are two boundaries that are unsafe to cross when overwriting samples: one from the left (normal write path), and one from the right (rewind path). No action items.
2. Discussion of the criteria when to enable timer-based scheduling. Suggestion: do not enumerate badness [*] when deciding whether to enable tsched in PulseAudio, because the bad things tend to go unreported by the drivers and people treat these as PulseAudio bugs. Move to a whitelist-based approach. The suggestion was rejected.
[*] BLOCK_TRANSFER (unimplemented), BATCH (implemented), huge FIFO (unimplemented), completely unrewindable (unimplemented, but a workaround for ioplug exists), what else?
3. Suggestion to revive the snd_pcm_hw_params_can_rewind() API function. Approved by Takashi.
4. Discussion whether the snd_pcm_rewindable() function is useful at all. The uselessness comes from the need to call snd_pcm_avail_update() beforehand, and the position of Clemens Ladisch that the result of snd_pcm_rewindable() must not take pointer granularity and other reasons why non-rewindable samples exist into account. That way, the caller can just deduce the result from the snd_pcm_avail_update() return value. David Henningsson does not like this situation. Mark Brown suggests reporting the DMA transfer size, with the possibility for architectures to override the returned value with something larger such as the cache line size.
5. Status report on rewind support in PCM plugins. Summary: at least 10 plugins out of 26 have known problems and should have rewind support either fixed (which is not always possible) or disabled.
Thanks Patrick