Perex at 10:09, 29 October 2018

2018-10-29T10:09:20Z

← Older revision		Revision as of 10:09, 29 October 2018
Line 206:		Line 206:
	* Error handling		* Error handling
	** OK to propagate errors		** OK to propagate errors

			==Slides==

			ftp://ftp.alsa-project.org/pub/talks/miniconf-2018/

Perex: /* Testin */

2018-10-24T08:50:25Z

Testin

← Older revision		Revision as of 08:50, 24 October 2018
Line 49:		Line 49:
	* Patrick & Liam to make introductions for QC auto team - may be interested		* Patrick & Liam to make introductions for QC auto team - may be interested

	==~~Testin~~==		==Testing==
	* Have HDA emulation		* Have HDA emulation
	* No unit tests to check for application breaks		* No unit tests to check for application breaks

Perex at 08:41, 24 October 2018

2018-10-24T08:41:46Z

← Older revision		Revision as of 08:41, 24 October 2018
Line 1:		Line 1:
	{\| align="right"		{\| align="right"
	\| __TOC__		\|See also [[Miniconf 2017]] __TOC__
	\|}		\|}

Perex at 08:23, 24 October 2018

2018-10-24T08:23:16Z

← Older revision		Revision as of 08:23, 24 October 2018
Line 1:		Line 1:
			{\| align="right"
			\| __TOC__
			\|}

	==Community==		==Community==

Perex: Created page with "==Community== ====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 o..."

2018-10-24T08:22:20Z

Created page with "==Community== ====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 o..."

New page

==Community==

====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

==Virtualisation==
* 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

==AVB==
* 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

==Testin==
* 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

==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
** Action Liam to chase upstreaming of ASoC Intel drivers
** Some modes could be implemented without hardware support, need to ask Pierre about generic stuff
** https://www.kernel.org/doc/html/latest/sound/designs/timestamping.html

==SoundWire==
* 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
* https://github.com/takaswie/sound/commits/topic/ctl-ioctl-refactoring
* kvmalloc() might be helpful for larger allocations

==GObject introspection==
* https://developer.gnome.org/gobject/stable/
* 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.
** https://github.com/diwic/alsa-rs/
** Example PCM code: https://docs.rs/alsa/latest/alsa/pcm/index.html
** Some interest from testing perspective.

==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

==PipeWire==
* 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

==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

====Documentation====
* Don’t use alsa
** https://thesofproject.github.io/latest/index.html
* ChromeOS will have a laptop out early next year using SoF

==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.

==Compress==
* 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

Miniconf 2018 - Revision history

Perex at 10:09, 29 October 2018

Perex: /* Testin */

Perex at 08:41, 24 October 2018

Perex at 08:23, 24 October 2018

Perex: Created page with "==Community== ====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 o..."