- No objection to adding a CoC - use the same one as the kernel is using
- Complaints handled by a list of maintainers, will work out who is on it later.
- SoF has the default github code of conduct
- Takashi to implement (make patches/list/whatever)
E-mail lists OK for everyone
- CI is nice with gitlab/github
- Consensus for userspace
- Jaroslav needs to buy in
- Vinod: what about the kernel?
- Mark: need to cope with people not working specifically on audio
- Intel/Linux Foundation might be able to help
- Takashi to bring it up on the list
- Mailing list archives
- Can we get them into Lore?
- Vinod will follow up with Konstantin/LF
- At intel there is a new hypervisor called ACRN. Presentation at ELC-E this week.
- Guests get subset of the card, eg a PCM and a volume control
- Android might want controls
- Liam making a virtio spec
- Need to be able to get the IPC from the guest going to a userspace daemon, can’t directly go to the host
- Liam to delegate looking at guest interfaces, Dylan will help
- Liam will be speaking to people from the KVM side
- Need to ensure that Arm people are looking at this
- Acorn supports buffer sharing with the host
- Cache coherency issues need to be handled - Mark/Peter/Arnd to loop in Marc Z, Alex Graf
- Newer ethernet PHYs support sending audio. Used in automotive use cases.
- For every ethernet frame inserting 6 audio frames
- x86 use case focuses on latency
- QC have some hardware
- Standard thing is to pass a file descriptor with a raw network socket into an ALSA driver
- Are the formats that the audio data is in a standard format? If so should be able to cut out transmission
- Feedback needed to hardware designers about this.
- ALSA plugin posted recently, not very good (Sakamoto-san reviewed)
- Sakamoto-san: look at FireWire, also timestamping in socket interface
- Liam will discuss with Sakamoto-san, make introductions with internal developers
- Takashi: do we need some cache flushing APIs? Intel need this in the firmware
- Patrick & Liam to make introductions for QC auto team - may be interested
- Have HDA emulation
- No unit tests to check for application breaks
- Would be good to have a dummy driver for use with virtual machine for testing
- Intel have some virtual drivers for BayTrail but they aren’t upstream in qemu
- Also needs some work to work without the DSP (Possible GSoC).
- Arun: Need better tooling / some framework for testing to make writing audio tests easier - Sakamoto-san’s gobject introspection might be helpful
- Sequencer has a dummy driver, but limited testsuite
- Intel has some tests, could upstream them.
- Once we have this stuff we can add CI
- Should be fuzzing these APIs as well
- syzcaller https://github.com/google/syzkaller
- Intel volunteering to upstream their bits, Cirrus volunteering to upstream their bits as well
- There is a git repository on alsa-project.org, currently empty
- Cmocha works well for SoF, might be useful for alsa-lib
- Peter: testing real devices?
- Cirrus have some stuff with a test farm.
- https://www.chromium.org/chromium-os/testing/chamelium-audio-board Google could provide a couple to Linaro?
- Makes reproduction of the testsuite harder
- Put it into hw_params? It’s more a cap than a parameter.
- Capability API better option, new ioctl()
- Dynamic things probably want to go into hwparams as user might want to control this
- Perhaps also expose some of this via sysfs, need to figure out which object to attach it to. May need new kobject
- Action on Takashi to propose stuff on the list
- Action Liam to chase upstreaming of ASoC Intel drivers
- Some modes could be implemented without hardware support, need to ask Pierre about generic stuff
- Liam was hoping to learn more about SoundWire status/plans
- Current code supports basic use cases (playback/capture out of the box)
- Bandwidth calculation is not present
- Controller instantiation for Intel isn’t there, the DSP needs to do that
- Multi-codec patches need review
- Ideally someone outside Intel needs to review as well, Intel hardware is very different to other people’s hardware
- Charles has done some good review already
- Needs rebase for Morimoto-san changes, also review comments from Pierre
- Pierre will chase up on multi-CPU DAI patches
- Vinod has a talk at 2pm tomorrow: https://sched.co/FwHM
Integrating ALSA control core
- dimen - just need to add comment in the header
- snd_ctl_elem_value has a max limit on number of elements, plan to remove it
- Some concern about increase in binary size, mainly in rodata
- kvmalloc() might be helpful for larger allocations
- Give us language bindings for many languages
- Used for libhinawa
- https://github.com/takaswie/alsa-gi presentation https://github.com/takaswie/presentations/blob/master/20181021/contents.md
- Using a separate thin ELF library
- Not actively developed right now due to time, but welcome contributions via github.
- Liam: latency impact (especially for getting position/pointer information)?
- No PCM yet
- Introspection done once at init
- David H wrote some rust bindings, also worth looking at - alsa-rs.
User defined elements on app close
- Sakamoto-san to post patch for auto cleanup
Allowing more user defined controls on cards
- Seems fine
PulseAudio new features
- Compressed offload support
- Vinod will make capabilities for PCM in compressed audio
- Timestamps associated with buffers
- Provide a low latency graph framework supporting video & audio
- Replace desktop stack (Pulse/Jack)
- One issue is handling configuration quirks
- Could reuse SoF algorithms
- How to tune seamless systems that mix gstreamer and ALSA in a single pipeline?
- Reusing HDA config
- PipeWire hackfest: https://wiki.gnome.org/Hackfests/PipeWire2018
- Arun to make sure that Mark and Liam can attend
Timestamps in compressed audio
- Some interest from Intel
- Link to presentation here
- Much discussion of configuration mechanisms
- Concerns about splitting domain & domain groups
- Issue with multiple unconnected instances of the same sample rate
Sound Open Firmware
- Talk on Wednesday
- Liam: Would like to be able to control trace for individual parts of the pipeline
- Mark: model is to post filter
- Rendering to ASCII can be done after the fact when the user asks to see the buffer
- Use compressed API for taking trace streams out of points of the graph
- Adding new stuff is fine, just need to keep compat with existing topology binaries
- Unloading topologies
- Intel doing this
- Current status
- Driver upstream will restart now because Pierre is back
- Can run on any platform, have it working on some Xiaomei platforms and with a RPi cape
- Some plans to add compressed platforms
- Don’t use alsa
- ChromeOS will have a laptop out early next year using SoF
ASoC/ALSA core merging
- Component mostly converted
- Need to think about how to handle USB
- Already covered, Sakamoto-san’s new elem API probably can have no limit if desired
- Vinod: it’s easier for usespace to handle a single userspace interface
- Charles: Cirrus has few large controls
- Having to extend every single UCM implementation is a pain
- tiwai: controls need to be readable at any time
- Calibration loading
- QC currently has a calibration mechanism parallel to standard ALSA one. QC code available on codeaurora. Want to re-do this with upstream constructs.
- 2 methods aware of upstream currently
- Pass calibration through byte control from user space
- Go through request firmware
- Discussion converging towards hwdep
- Vinod: fudge hwdep in alsa-lib
- Charles: happy to investigate what the hwdep solution would look like from cirrus PoV
- Patrick: need to provide different calibration data depending on sample rate.
- UCM: Problems with Android but otherwise good
Exposing graph at runtime
- Media Controller?? Maybe not worth the extra complexity. Could just export the DAPM graph we already have.
- Vinod: can we read back topology data? wv Vinod
- Would like to expose the DSP graph for use with the calibration tool
Batching commands up
- One option is to just spam out the startup stuff asynchronously
- Could also flag which things failed and punt to userspace
- Intel has some stuff they’re looking at in SoF, could look at making that more generic after it’s upstream.
- Tinycompress will be integrated with ffmpeg to give better test coverage
- Make it a separate binary/optional build to avoid license contamination from ffmpeg
- Should add any header stripping information to the caps exposed by the drivers
- Look at integration with gstreamer
- Error handling
- OK to propagate errors