asgardius/alsa-utils
1
0
Fork 0
mirror of https://github.com/alsa-project/alsa-utils synced 2024-11-10 04:45:42 +01:00
Code Issues Projects Releases Packages Wiki Activity
alsa-utils/axfer/Makefile.am

50 lines
711 B
Makefile
Raw Normal View History

axfer: add an entry point for this command 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:13 +01:00
bin_PROGRAMS = \
axfer
# To include headers for gettext and version.
AM_CPPFLAGS = \
-I$(top_srcdir)/include
# Unit tests.
axfer: add unit test for container interface 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:20 +01:00
SUBDIRS = \
test
axfer: add an entry point for this command 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:13 +01:00
LIBRT = @LIBRT@
LDADD = \
$(LIBINTL) \
$(LIBRT)
noinst_HEADERS = \
misc.h \
axfer: add a common interface to handle a file with audio-specific data 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:15 +01:00
subcmd.h \
axfer: add a common interface to align data frames on different layout 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:21 +01:00
container.h \
axfer: add a common interface to transfer data frames 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:25 +01:00
mapper.h \
axfer: add support to transfer data frames by alsa-lib PCM APIs 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:27 +01:00
xfer.h \
axfer: add support for blocking data transmission operation of alsa-lib 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:28 +01:00
xfer-libasound.h \
frame-cache.h
axfer: add an entry point for this command 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:13 +01:00
axfer_SOURCES = \
misc.h \
subcmd.h \
axfer: add a sub-command to print list of PCMs/devices 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:14 +01:00
main.c \
axfer: add a common interface to handle a file with audio-specific data 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:15 +01:00
subcmd-list.c \
container.h \
axfer: add support for a container of Microsoft/IBM RIFF/Wave format 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:16 +01:00
container.c \
axfer: add support for a container of Sparc AU format 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:17 +01:00
container-riff-wave.c \
axfer: add support for a container of Creative Tech. voice format 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:18 +01:00
container-au.c \
axfer: add support for a container of raw data 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:19 +01:00
container-voc.c \
axfer: add a common interface to align data frames on different layout 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:21 +01:00
container-raw.c \
mapper.h \
axfer: add support for a mapper for single target 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:22 +01:00
mapper.c \
axfer: add support for a mapper for multiple target 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:23 +01:00
mapper-single.c \
axfer: add a common interface to transfer data frames 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:25 +01:00
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 \
axfer: add support to transfer data frames by alsa-lib PCM APIs 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:27 +01:00
xfer-options.c \
xfer-libasound.h \
axfer: add support for blocking data transmission operation of alsa-lib 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:28 +01:00
xfer-libasound.c \
frame-cache.h \
frame-cache.c \
axfer: add a sub-command to transfer data frames 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> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 07:41:29 +01:00
xfer-libasound-irq-rw.c \
subcmd-transfer.c
Reference in a new issue Copy permalink