Revision as of 09:47, 24 October 2018 by Perex
- API update summary - Takashi
- Some dicussion of topology, need to make sure it doesn't get any new ABI changes.
- Userspace release schedule
- Once per two kernels, seems fine for everyone.
- Can split UCM files more easily.
Move to github?
- Sakamoto-san: Could get many issues reported by users with bug tracker!
- Accept pull requests?
- Currently have no bug tracker, this would give us one.
- Jaroslav will mirror the git repos and see how it goes.
Removing older drivers
- Kernel build of OSS already disabled, nobody noticed.
- Perhaps remove in next release or so.
- Probably too big a patch, perhaps just announce.
- Still some OSS leftovers.
- No ALSA m68k support, still some users for that! Needs port of ALSA drivers. Not high priority.
- Some discussion of possibility of deprecating ISA
- Generally feeling was to hang on until last of the 32-bit support in the distro's dies off
- ASoC has a lot of "dead" drivers
- Mostly very thin and not causing a maintainence issue
- Overhead from IPC, everything goes through HIDL. Fast message queue implemented via a shared memory area.
- Could impact proprietary configuration mechanisms.
- Limited attendance from OEMs/SoC vendors, Cirrus quite positive.
- Potential issue with sound trigger HAL needing to interface with primary HAL, xternal CODEC vendor needs to get the audio stream. Could resolve by having audio modules for particular stream types.
- Switch to message sever has increased latency/jitter but not too bad.
- SCHED_DEADLINE not reliable enough in kernel in use, worth revisiting later with newer kernels.
axfer as a replacement for aplay/arecord
- aplay is a sample/test program used as a test program by driver authors but it's not very good.
- Badly structured, buggy, not typical of real applications.
- No useful position reporting tests.
- No timer based scheduling like PulseAudio.
- Jaroslav is very sorry :)
- New program called axfer https://github.com/takaswie/alsa-utils/tree/topic/axfer
- Iwai-san - can we have runtime tests as well as make check?
- Sakamoto-san - no,
- Peter - can we replace arecord too, lots of problems reported by users with slow sdcards.
- Sakamoto-san - yes.
- Which modes supported? Can we test them individually/explicitly?
- General plan is to keep backwards compatibility.
- Remove vumeter? People use it when testing recording or during remote testing but Sakamoto-san not keen.
- Interactive pause/resume - useful for testing pause/resume on stream.
- axfer currently does pause on suspend signal, users sometimes suspend deliberately.
- Could have command line option.
- chmap might not work, remove due to thus.
- Jaroslav: all features used somewhere
- Users can implement them later though.
- People generally enthusiastic.
- Transision both the echoaudio driver and the echomixer application to not rely on dimen.
(Maybe) evently remove dimen and upgrade ALSA ABI version
- USB PCM handling
- Currently high latency, start audio stream before audio gets triggered.
- Allow applications to queue data while things are in flight to minimize in kernel delay?
- Emulate ring buffer in kernel?
- Probably doesn't fix anything.
- Can we directly map buffers to userspace?
- Deal with buffer size/alignment issues with constraint on 1ms period size?
- Would be good to implement in ASoC - dmaengine needs extension for scatter/gather cyclic buffers
Android - mmap no IRQ read/write mode
- Treble has a negative impact on read/write latency and additional context switches
- USB-C has impact on latency: needs more buffering
- New Audio API in Android O release (https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)
- Designed for low-latency and high-performance
- Allows applications to use mmap (legacy stream is supported)
- For applications mmap is transparent, will be used when available
- Does not use binder
- Timing model will randomly read current stream position pointer and generate model from it with earliest and latest arrival times
- Discussion: The driver knows the burst size, can we communicate this to userspace to improve the model?
- For security reason the app does not get a direct pointer to the buffer. Write method is provided that will copy data from application buffer to audio buffer
- How to share buffer with applicaiton?
- Treble model prevents shared memory
- Need to split control from data
- Solution: data only buffer, dmabuffer based, ION, custom hwdep IOCTL
- Discussion: Could be implemented in mainline without ION
- How well is MMAP no IRQ supported by SoC vendors
- Answer: It is always broken
- Accurate frame position and timestamp reporting
- What about a standard kernel API for shareable FD for MMAP data buffer
- Answer: Use dmabuf infrastructure, use new IOCTL to get file handle
- Linaro to help out here
- How well is MMAP no IRQ supported by SoC vendors
- 32-bit timespec will overflow in 2038 and needs to be replaced with 64-bit timespec
- Problem: Different architectures have different timespec64 implementations => conversion is messy
- Upgrading will break the ABI anyway, might as well replace timespec64 with a uint64_t nanoseconds monotonic timestamp
- Userspace needs to split timestamp into seconds and microseconds, but will be easier for kernel side
- Question: Do we want a simplified API or introduce helper functions in the kernel to convert beyween timespecs.
- Answer: Both seem to be viable options
- Conclusion: There will be an API/ABI change to support >2038 timestamps, seems like a good time to overhaul the timestamping API
- Fix now, time is running out
TLV API for binary controls
- Picking up the discussion from last year.
- Problem: Can't figure out what kind of TLV control it is
- It's a hack to use TLV for binary controls, probably worth reconsidering.
- Only users are Cirrus and Intel. Only for controls with more than 512 bytes for Cirrus.
- Tidy up existing one? Add a flag saying that it's binary nonsense - disagreement.
- Add TLV headers in the data? Probably breaks Intel who have headers that look like they mean something.
- One goal for using TLV was to get data through existing API clients.
- Takashi would prefer to add a new API for this.
- Indirect pointers sound complicated.
- Maybe use file based interface (ioctl takes a fd).
- Sounds like new ioctls, Charles volunteers to implement.
Clock handling using the Common Clock Framework (CCF)
- Want to be able to use external clock generator chips for generating audio clock.
- People would like to see ASoC move to the CCF, but the clock framework is not ready for all the audio requirements.
- Single lock breaks with SPI
- SPI master driver will try to enable its clock from within the clock control callbacks of the external chip
- Only an issue for CODECs, on SoC devices don't have these lockups and can be converted.
- Probe ordering issues
- How to enumerate available clock rates of a clock provider - already a problem for ASoC specific stuff, converting to CCF won't make anything worse and we can fix there.
- Where to start.
- Switch constraints system to a multi context capable implementation.
- Grouping widgets into domains
Sound Card Ordering
- Probe ordering is not fixed
- udev is the standard way to solve these problems for broader kernel issues.
- Slot fixing command line options.
- Should work fine but may be buggy.
- Should scale, if not fix - use range ops when building debugfs file for faster performance.
- #defines - lots of them, is it a problem?