Miniconf 2018

From AlsaProject
Revision as of 11:09, 29 October 2018 by Perex (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
See also Miniconf 2017



Community governance

  • 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
  • Intel volunteering to upstream their bits, Cirrus volunteering to upstream their bits as well
  • There is a git repository on, currently empty
  • Cmocha works well for SoF, might be useful for alsa-lib
  • Peter: testing real devices?

PCM improvements

  • Granularity
    • 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
  • Timestamping


  • 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:

Integrating ALSA control core

GObject introspection

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:
    • Arun to make sure that Mark and Liam can attend

Timestamps in compressed audio

  • Some interest from Intel

Rate domains

  • 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

Topology ABI

  • 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
  • MP3
    • Some plans to add compressed platforms


ASoC/ALSA core merging

  • Component mostly converted
  • HDA
  • Need to think about how to handle USB

Byte controls

  • 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


Custom Search
Personal tools