alsa-utils/axfer/Makefile.am

73 lines
1 KiB
Makefile
Raw Normal View History

bin_PROGRAMS = \
axfer
man_MANS = \
axfer.1 \
axfer-list.1 \
axfer-transfer.1
# To include headers for gettext and version.
AM_CPPFLAGS = \
-I$(top_srcdir)/include
# Unit tests.
SUBDIRS = \
test
LIBRT = @LIBRT@
LDADD = \
$(LIBINTL) \
$(LIBRT)
noinst_HEADERS = \
misc.h \
subcmd.h \
container.h \
mapper.h \
xfer.h \
xfer-libasound.h \
frame-cache.h
waiter.h
axfer_SOURCES = \
misc.h \
subcmd.h \
main.c \
subcmd-list.c \
container.h \
container.c \
container-riff-wave.c \
container-au.c \
container-voc.c \
container-raw.c \
mapper.h \
mapper.c \
mapper-single.c \
mapper-multiple.c \
xfer.h \
axfer: add a parser for command-line options 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:26 +01:00
xfer.c \
xfer-options.c \
xfer-libasound.h \
xfer-libasound.c \
frame-cache.h \
frame-cache.c \
xfer-libasound-irq-rw.c \
subcmd-transfer.c \
xfer-libasound-irq-mmap.c \
waiter.h \
waiter.c \
waiter-poll.c \
waiter-select.c \
axfer: add support for timer-based scheduling model with MMAP operation 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:45 +01:00
waiter-epoll.c \
xfer-libasound-timer-mmap.c
if HAVE_FFADO
axfer_SOURCES += xfer-libffado.c
LDADD += -lffado
endif
EXTRA_DIST = \
axfer.1 \
axfer-list.1 \
axfer-transfer.1