Commit graph

9 commits

Author SHA1 Message Date
Jaroslav Kysela
feb9c4cdec reshuffle included files to include config.h as first
config.h may contain defines like _FILE_OFFSET_BITS which influence
the system wide include files (off_t types, open -> open64 function
usage etc.).

Related: https://github.com/alsa-project/alsa-utils/pull/223
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2023-08-30 18:48:23 +02:00
Takashi Sakamoto
97fe7b550c axfer: enable each backend to print own help
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>
2018-12-07 10:57:44 +01:00
Takashi Sakamoto
6548d13582 axfer: add support for libffado transmission backend
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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 12:04:53 +01:00
Takashi Sakamoto
f5776e232c axfer: add options related to duration and obsolete '--max-file-size' 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>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-11-13 12:04:35 +01:00
Takashi Sakamoto
ae378611b7 axfer: add an option to dump available hardware parameters
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>
2018-11-13 12:04:35 +01:00
Takashi Sakamoto
2b4d826893 axfer: add informative output and an option to suppress it
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>
2018-11-13 12:04:34 +01:00
Takashi Sakamoto
ae7346d110 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 12:04:31 +01:00
Takashi Sakamoto
b83a8cd3be 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 12:04:30 +01:00
Takashi Sakamoto
4ab0c46165 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 12:04:29 +01:00