A function, print_help() in xfer module is defined to return integer
value, however this is useledd.
This commit fixes it.
Fixes: 908ff69be2 ('axfer: print help text of transfer subcommand just for common options')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds an operation for xfer backend to print help text.
In this time, content of the help is not implemented yet.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds help text of transfer subcommand.
In this time, backend options are not described. They will be added in
future commits.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
