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