Commit graph

6 commits

Author SHA1 Message Date
Jaroslav Kysela
ad5a1c0c88 axfer: fix the verbose compilation warnings for latest gcc
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
2023-08-30 12:35:57 +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
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