alsa-utils: axfer: rewrite aplay, adding 'timer-based scheduling' option #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds a new command, 'axfer' ('ALSA transfer'), to transfer data
frames described in asound.h. This command is intended to replace current
aplay. The most of features and command line parameters come from aplay as
much as possible, while it has more better feature and code to maintain.
This commit adds an entry point for this command. Current option system of
aplay is still available, while this command has a sub-command system like
commands in iproute2.
Currently, two sub-commands are supported; 'list' and 'transfer'. The
'list' sub-command has the same effect as '-l' and '-L' options of aplay.
The 'transfer' sub-command has the same effect as the main feature of
aplay. For the sub-command system, an option for stream direction is
required; '-P' for playback and '-C' for capture. If you create symbolic
links to this binary for aplay/arecord, please execute:
$ ln -s axfer aplay
$ ln -s axfer arecord
Actual code for each sub-command will be implemented in later commits.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Original aplay implementation has a feature to output two types of list;
devices and PCMs. The list of devices is a result to query sound card and
pcm component structured maintained in kernel land. The list of PCMs is a
result to parse runtime configuration files in alsa-lib. Entries in the
former list is corresponding to ALSA PCM character device
('/dev/snd/pcm%uC%uD[p|c]'), while entries in the latter list includes
some 'virtual' instances in application runtime.
This commit adds an implementation for the above functionality. This is
executed by taking 'list' sub-command. A 'device' option has the same
effect as '--list-devices' and '-L' of aplay. A 'pcm' option has the same
effect as '--list-pcms' and '-l' of aplay. In both cases, an additional
option is required for stream direction. Below is examples of new command
system for this sub-command.
$ axfer list device -C (= arecord --list-devices)
$ axfer list pcm -P (= aplay -l)
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
…ta format Current aplay supports several types of data format for file; Microsoft/IBM RIFF/Wave (.wav), Sparc AU (.au) and Creative Tech. voice (.voc). These formats were designed to handle audio-related data with interleaved frame alignment. This commit adds a common interface to handle the file format, named as 'container' module. This includes several functions to build/parse the format data from any file descriptors. Furthermore, this includes several helper functions for implementations of each builder/parser. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support for data of Microsoft/IBM RIFF/Wave format. In this data format, values in each of field are encoded in both bit/little byte order but inner a file the same order is used. Magic bytes in the beginning of data indicated which byte order is used for the file. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support for data of Sparc AU format. In this data format, values in each of field are encoded in big-endian byte order and available formats of data sample are restricted in big-endian byte order. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support for data of Creative Tech. voice format. In this data format, values in each of field are represented in little-endian byte order and available formats of data sample are restricted in little-endian byte order. In version 1.10 of this format, sampling rate is represented with reciprocal number of the rate, thus we cannot calculate original sampling rate precisely just from its header. For example at 44.1kHz, file header includes 233 (=256-1,000,000/44,100), but we cannot recover the value just from the code (43478.2...). For my convenience, this commit adds a pre-computed table and lookup major rates from the table. Additionally, this format can includes several blocks with different sample format. When handling this type of file, we need to start/stop substream for each of the block, while this brings complicated code. This type of format is enough ancient and presently quite minor. This commit takes a compromise and handles a first sample block only. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support for raw data without any headers/chunks/blocks. A parser of container cannot recognize format of sample without supplemental information. Additionally, it includes no magic bytes. A parser of container should process first several bytes as a part of PCM frames, instead of magic bytes. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In former commits, container module gets supports of parser/builder for several types of file format. This commit adds a unit test for them. This includes positive test cases only. The test cases actually generate I/O to file systems for many test cases. It takes a long time to finish. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In current aplay, several files can be handled as source of data frames for playback, or destination of captured data frames by an option '--separate-channels' (-I). On the other hand, in ALSA PCM kernel/user interface, several types of buffer are used to communicate between application/hardware; - mapped page frame for data frames with interleaved alignment - mapped page frame for data frames with non-interleaved alignment - buffer in user space for data frames with interleaved alignment - a list of buffer in user space for data frames with non-interleaved alignment This commit adds a common interface, named as 'mapper' to convert frame alignment between these two sides. This interface includes two types; 'muxer' and 'demuxer'. The 'muxer' is for playback direction, to construct playback buffer with PCM frames from several files. The 'demuxer' is for capture direction, to split PCM frames from capture buffer to each of file. Unlike multimedia containers such as MPEG 2/4 Systems, the 'muxer' and 'demuxer' are for playback/capture buffer, not for file contents. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In usual use case of aplay, single file is used to playback or capture data frames. This commit adds support of single type mapper for this use case. All of supported file format can include data frame with interleaved alignment, thus this mapper have a functionality to convert from several types of data frame alignment to interleaved alignment or vise versa. When handling non-interleaved buffer, a caller should use an array of buffer for each of channels with non-interleaved data frames. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support of mapper for 'multiple' target. This handles several files via 'container' functions, and constructs data frame buffer for playback, or splits data frames from data frame buffer for capture. When playback source files includes data frames with several channels, the first channel is used to construct buffer. For capture direction, each of channel of data frame is stored in one file, thus the file includes one channel of data frame. When handling non-interleaved buffer, a caller should use an array of buffer for each of channels with non-interleaved data frames. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In former commits, mapper module gets supports of muxer/demuxer for single/multiple targets for playback source or capture destination. This commit adds a unit test for them. This includes positive test cases only. The test cases actually generate I/O to file systems for many test cases. It takes a bit long time to finish. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
ALSA has PCM interface to transfer data frames. In userspace, there're some implementation to utilize this interface to produce application programming interface; alsa-lib (libasound) and tinyalsa. However, it's possible to use the interface with raw I/O operations. This commit adds an common interface to transfer data frames for this program, named as 'xfer'. This internal interface is designed for users to select several backend for data transmission. This includes some functions expected to be called by main program just for data transmission. In an aspect to maintain PCM substream, suspend feature is required to handle a pair of SIGTSTP/SIGCONT UNIX signals. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In aplay, many command-line options are supported. Some of them have
dependency or conflicts. Furthemore, some of them are just for
runtime configuration of alsa-lib(libasound), and some options can
be used by several xfer backends commonly; e.g. options for file name,
sample format and sampling rate.
This commit adds a parser for the common options below.
* --help (-h)
* Just output 'help' string (not written yet).
* --verbose (-v)
* For verbose output, including information about xfer, mapper and
container.
* --format (-f): string. format literals or one of ['cd'|'cdr'|'dat']
* For sample format supported by ALSA PCM interface. Special format
can be used. For playback, this is auto-detected according to actual
file format.
* --channels (-c)
* For the number of samples included in one data frame. For playback,
this is auto-detected according to actual file format, except for
'raw' format. This option can conflict to above format option.
* --rate (-r)
* For the number of data frames transferred in one second. For playback,
this is auto-detected according to actual file format, except for
'raw' format. This option can conflict to format option above.
* --file-type (-f): string. one of ['wav'|'au'|'voc'|'raw']
* For format of files of given paths. For playback, this is optional
because the format is auto-detected. For capture, this is optional too
because the format is decided according to suffix of given path.
Anyway, this option is used for cases to fail to detect or decide.
* --separate-channels (-I)
* When using several files as source or destination for transmission
of data frame, this option can be used with several file paths.
When '--separate-channels' option is used, users can give several file
paths to source/destination of data transmission, else they can give single
file path for the purpose. When multiple files are handled by this option,
for playback, data frames in first channel is used to construct buffer for
data transmission with multi channel. For capture, data frames in each
channel of buffer are written to each of given path. Furthermore, when a
single path is given for capture, file paths are auto-generated according
to available number of channels. For example, 'name.wav' is given for
2 channels capture, 'name-0.wav' and 'name-1.wav' are generated. In a
case of no suffix, 'name-0' and 'name-1' are generated.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support fo alsa-lib PCM API as a backend of 'xfer' module. In a set of alsa-lib PCM API, there're two ways to handle data frames; by calling ioctl(2) with some specific commands with buffer in user space, or copying data frames on mapped page frames. To support both ways, this commit adds an operation structure as abstraction. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
…ib PCM API In alsa-lib PCM API, snd_pcm_read[i|n]() and snd_pcm_write[i|n]() are used to transfer data frames from/to hardware. When a handler is not opened with specific flags, these functions perform blocking operation; i.e. the function call doesn't return till all of request number of data frames are actually handled, or call is interrupted by Unix signals, or PCM substeam corrupts due to hardware reasons. This commit adds support for this type of data transmission. For cases that requested data frames are not processed by container interface, this commit adds internal cache mechanism to handle rest of data frames in next timing. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In current aplay, default action is to transfer data frames from/to devices. This commit adds support for this functionality. Event loop is included in an added file. In the loop, the number of handled data frames is manipulated by an appropriate way. As a result, users can stop data transmission frames by frame. Unlike aplay, when catching SIGSTP, this application performs to suspend PCM substream. When catching SIGCONT, it performs to resume the PCM substream. The aim of this design is to avoid XRUN state of the PCM substream. If users/developers need to any XRUN-recovery test, it's better to work for the other ways. Below lines are examples to execute: $ axfer transfer -P -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer -C -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In current aplay, some informative output is available as a default. This can be suppressed by a quiet option. This commit adds support for it. An original aplay implementation has no effect of this option in a case to handle multiple files. However, in a point of usability, this commit support this case. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In ALSA PCM interface, before configuring hardware actually, applications can request available set of hardware parameters for runtime of PCM substream. The set of parameters are represented and delivered by a structure. In alsa-lib PCM API, the above design is abstracted by a series of snd_pcm_hw_params_xxx() functions. An actual layout of the structure is hidden from applications by an opaque pointer. In aplay, '--dump-hw-params' option is for this purpose. With this option, the command output available set of the hardware parameters. This commit adds support for the option. Unlike aplay, this commit takes this program to finish after dumping the parameters for simplicity of usage. I note that all of combinations in the set are not necessarily available when the PCM substream includes dependencies of parameters described by constraints and rules. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
… option In aplay, some options are available to stop data transmission by frame unit. This commit adds support for the options below: * --duration (-d) * For duration seconds. The number of data frames transferred in this * runtime is calculated by this value and sampling rate. * --samples (-s) * For the number of data frames to handle in this runtime. An original aplay has a similar option; '--max-file-time'. This option is used for capture data transmission to switch file to write data frame up to maximum number of frames which container format supports, instead of terminating. However, this may brings complicated file handling to this program. To reduce maintaining cost, this option is obsoleted. Additionally, a handler for SIGUSR1 Unix signal has similar feature to switch the file. For the same reason, the handler is also obsoleted. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In aplay, '--fatal-errors' option has an effect to give up recovery of PCM substream from XRUN state. This commit adds support for this option. In original implementation, this option brings program abort. This seems to generate core dump of process VMA. However, typically, XRUN comes from timing mismatch between hardware and application, therefore core dump has less helpful. This commit finishes this program in usual way with this option at XRUN. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In alsa-lib PCM API, snd_pcm_read[i|n]() and snd_pcm_write[i|n] can be used with non-blocking mode. This is available when SND_PCM_NONBLOCK is used as 'mode' argument for a call of snd_pcm_open(). This commit adds support this type of operation. To reduce CPU usage, this commit uses 'snd_pcm_wait()' to wait for event notification. Below lines are examples to execute: $ axfer transfer -N -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer -N -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In alsa-lib PCM API, data frames can be handled in mapped page frame, instead of calling any system calls. This commit support for this type of operation. To reduce CPU usage, this commit uses 'snd_pcm_wait()' to wait for event notification. Below lines are examples to execute: $ axfer transfer -M -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer -M -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In aplay, '--test-nowait' is used to suppress calls of snd_pcm_wait() when I/O operations return -EAGAIN or process truncated number of data frames. This seems to be for debugging purpose. In this program, this option is equivalent to suppress event waiting. This commit adds support for this option. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In ALSA PCM interface, two parameters are used for size of intermediate buffer for data frames; period size and buffer size. Actual effects of these sizes differs depending on hardware, but basically the size of period is used for intervals of hardware interrupts and the size of buffer is used to maintain the intermediate buffer as ring buffer. These parameters can be configured as a part of hardware parameters by data frame unit or micro second. PCM API in alsa-lib also includes helper functions to configure them by the two units. This commit adds support for options to the parameters by both units. When no options are given, default values are applied according to current aplay; available maximum size of buffer up to 500msec, a quarter of the size of buffer for period size. However, these calculation should be reconsidered somehow. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In ALSA PCM interface, some parameters are used to configure runtime of PCM substream independently of actual hardware. These parameters are mainly used to decide the detailed timing to start/stop PCM substream and release I/O blocking state of application. These parameters are represented and delivered by a structure. In alsa-lib PCM API, the structure is hidden from userspace applications. The applications can set/get actual parameters by helper functions. In aplay, three of the parameters are configurable. This commit adds support for them. When no options are given, default values are used. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
As of 2017, two userspace library implementations are known; alsa-lib and tinyalsa. The latter is simple I/O library to use ALSA PCM interface. On the other hand, alsa-lib is more complicated than it. This is because it's designed to add features to transmission of data frames; e.g. sample resampling. To achieve this, alsa-lib has its configuration space and plugin system. In aplay, some options are implemented as a flag for the plugins in alsa-lib. The flag is given to snd_pcm_open(). This commit adds support for the flags. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
There're several types of system calls for multiplexed I/O. They're used to receive notifications of I/O events. Typically, userspace applications call them against file descriptor to yield CPU. When I/O is enabled on any of the descriptors, a task of the application is rescheduled, then the application execute I/O calls. This commit adds a common interface for this type of system calls, named as 'waiter'. This is expected to be used with non-blocking file operation and operations on mapped page frame. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit is an integration to add an option for users to choose waiter
type. Users give the type to value to '--waiter-type' ('-w') option to
choose it. Currently, 'snd_pcm_wait()' is just supported as a default.
This alsa-lib API is implemented with a call of poll(2).
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support of waiter for poll(2) system call. Below lines are examples to use this option: $ axfer transfer --waiter-type=poll -M -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer --waiter-type=poll -M -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support of waiter for select(2) system call. Below lines are examples to use this option: $ axfer transfer --waiter-type=select -M -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer --waiter-type=select -M -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
This commit adds support of waiter for Linux specific epoll(7) system call. For portability to the other Unix-like systems such as xBSD, modification of Makefile.am may be required for conditional build, but this commit includes no changes for it. Below lines are examples to use this option: $ axfer transfer --waiter-type=epoll -M -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer --waiter-type=epoll -M -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In 2010, ALSA PCM interface got an flag of hardware parameters to suppress periodical interrupts, according to a request from PulseAudio developer. In typical PCM operation for usual hardware, PCM drivers configure the hardware to generate the periodical interrupts to notify that the same amount of data frames as a period of PCM buffer is actually transferred via serial sound interface. The flag can suppress this if the driver support it. There's some merits of this configuration: - No interrupt context run for PCM substream. The PCM substream is handled in any process context only. No need to care of race conditions between interrupt/process contexts. This is good for developers of drivers and applications. - CPU time is not used for handlers on the interrupt context. The CPU time can be dedicated for the other tasks. This is good in a point of Time Sharing System. - Hardware is not configured to generate interrupts. This is good in a point of reduction of overall power consumption. Disabling period interrupt is used for 'Timer-based scheduling' to consume data frames on PCM buffer independently of interrupt context. As noted, no interrupt context runs for PCM substream, thus any blocking operation is not released. Furthermore, system calls for multiplexed I/O is not also released without timeout. In this scheduling model, applications need to care of available space on PCM buffer by lapse of time, typically by yielding CPU and wait for rescheduling. For the yielding, timeout is calculated for preferable amount of PCM frames to process. This is an additional merit for applications, like sound servers. when an I/O thread of the server wait for the timeout, the other threads can process data frames for server clients. Furthermore, with usage of rewinding/forwarding, applications can achieve low latency between transmission position and handling position even if they uses large size of PCM buffers. But the timeout should be calculated with enough care of hardware capabilities. To disable period interrupt, used hardware should satisfy some requirements for data transmission: 1. Even if drivers don't handle interrupts to queue next data transmission, hardware voluntarily perform the data transmission when needed (typically by requesting DMA automatically). 2. hardware has a capability to report current position of data transmission with enough accuracy against the data transmission. developers refer this as 'granularity'. If hardware can always reports updated position after the data transmission finishes, the granularity equals to the size of period of PCM buffer. 3. a fine size of data transmission in one time. This size is decided depending on configuration of hardware or DMA controller, but for efficiency it may not be one byte. Thus some amount of data frame is transferred by one data transmission. Developers refer this as 'burst-ness'. The timeout should be calculated according to the item 2 and 3, however in current ALSA PCM interface supplemental information is not delivered from drivers to applications. Although at present userspace applications should be written by a speculative way for this point, there's few problems because there're a few hardware which satisfy the above items. However, when more drivers supports this feature, the problem may largely be exposed and bothers application developers. This commit adds an option to use 'timer-based scheduling' for data transmission. This commit adds '--sched-model' option, and the scheduling mode is enabled when 'timer' is assigned to the option by equal sign. Although there's some TODOs, you can see the scheduling mode in this simple program, like: $ axfer transfer --sched-model=timer -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv $ axfer transfer --sched-model=timer -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Althogh many options are actually supported by aplay, some of them are not enough good in practical points. For example, '--test-position' option is meaningless for some use cases. Furthermore, due to practical reasons, some options are not implemented well; e.g. vumeter. This commit marks such options as 'obsoleted'. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
At present, axfer is designed to use several types of backend for transmission of data frames. This commit is an implementation example of the backend. Libffado is a userspace library for transmission of data frames according to protocols similar to IEC 61883-1/6. This library handles audio and music units on IEEE 1394 bus. Unfortunately, this library executes ctor/dtor of instances for some objects in startup/finish routines of C runtime. As a result, it outputs some superfluous messages even if the backend is not actually used. Furthermore, this library brings memory leak internally. Therefore, it's not practical to build this backend for generic purposes. Although the backend implementation works fine, this commit is just for technical preview. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
Thanks, now merged all patches. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
This patchset is an updated version of my previous RFCv3, and for
merging to upstream.
[alsa-devel] [RFCv3][PATCH 00/39] axfer: rewrite aplay, adding 'timer-based scheduling' option
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-October/125961.html
As I noted in RFCv3, some patches are dropped in this patchset, due to
some technical issues. In detail, please refer to RFCv3.
Changes from RFCv3:
several backends.
library brings problems. Please refet to patch comment.)
I apologize but in this time I don't prepare any help document and
manuals as well as RFCv3. Let me put them to a part of task for this
development period.
Regards
Takashi Sakamoto (35):
axfer: add an entry point for this command
axfer: add a sub-command to print list of PCMs/devices
axfer: add a common interface to handle a file with audio-specific
data format
axfer: add support for a container of Microsoft/IBM RIFF/Wave format
axfer: add support for a container of Sparc AU format
axfer: add support for a container of Creative Tech. voice format
axfer: add support for a container of raw data
axfer: add unit test for container interface
axfer: add a common interface to align data frames on different layout
axfer: add support for a mapper for single target
axfer: add support for a mapper for multiple target
axfer: add a unit test for mapper interface
axfer: add a common interface to transfer data frames
axfer: add a parser for command-line options
axfer: add support to transfer data frames by alsa-lib PCM APIs
axfer: add support for blocking data transmission operation of
alsa-lib PCM API
axfer: add a sub-command to transfer data frames
axfer: add informative output and an option to suppress it
axfer: add an option to dump available hardware parameters
axfer: add options related to duration and obsolete '--max-file-size'
option
axfer: add an option to finish transmission at XRUN
axfer: add support for non-blocking operation
axfer: add support for MMAP PCM operation
axfer: add an option to suppress event waiting
axfer: add options for buffer arrangement
axfer: add options for software parameters of PCM substream
axfer: add options for plugins in alsa-lib
axfer: add a common interface of waiter for I/O event notification
axfer: add an option for waiter type
axfer: add an implementation of waiter for poll(2)
axfer: add an implementation of waiter for select(2)
axfer: add an implementation of waiter for epoll(7)
axfer: add support for timer-based scheduling model with MMAP
operation
axfer: obsolete some unimplemented options
axfer: add support for libffado transmission backend