2018-11-13 07:41:13 +01:00
|
|
|
bin_PROGRAMS = \
|
|
|
|
|
axfer
|
|
|
|
|
|
2018-12-05 22:31:46 +01:00
|
|
|
man_MANS = \
|
|
|
|
|
axfer.1
|
|
|
|
|
|
2018-11-13 07:41:13 +01:00
|
|
|
# To include headers for gettext and version.
|
|
|
|
|
AM_CPPFLAGS = \
|
|
|
|
|
-I$(top_srcdir)/include
|
|
|
|
|
|
|
|
|
|
# Unit tests.
|
2018-11-13 07:41:20 +01:00
|
|
|
SUBDIRS = \
|
|
|
|
|
test
|
2018-11-13 07:41:13 +01:00
|
|
|
|
|
|
|
|
LIBRT = @LIBRT@
|
|
|
|
|
LDADD = \
|
|
|
|
|
$(LIBINTL) \
|
|
|
|
|
$(LIBRT)
|
|
|
|
|
|
|
|
|
|
noinst_HEADERS = \
|
|
|
|
|
misc.h \
|
2018-11-13 07:41:15 +01:00
|
|
|
subcmd.h \
|
2018-11-13 07:41:21 +01:00
|
|
|
container.h \
|
2018-11-13 07:41:25 +01:00
|
|
|
mapper.h \
|
2018-11-13 07:41:27 +01:00
|
|
|
xfer.h \
|
2018-11-13 07:41:28 +01:00
|
|
|
xfer-libasound.h \
|
|
|
|
|
frame-cache.h
|
2018-11-13 07:41:40 +01:00
|
|
|
waiter.h
|
2018-11-13 07:41:13 +01:00
|
|
|
|
|
|
|
|
axfer_SOURCES = \
|
|
|
|
|
misc.h \
|
|
|
|
|
subcmd.h \
|
2018-11-13 07:41:14 +01:00
|
|
|
main.c \
|
2018-11-13 07:41:15 +01:00
|
|
|
subcmd-list.c \
|
|
|
|
|
container.h \
|
2018-11-13 07:41:16 +01:00
|
|
|
container.c \
|
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 \
|
2018-11-13 07:41:19 +01:00
|
|
|
container-voc.c \
|
2018-11-13 07:41:21 +01:00
|
|
|
container-raw.c \
|
|
|
|
|
mapper.h \
|
2018-11-13 07:41:22 +01:00
|
|
|
mapper.c \
|
2018-11-13 07:41:23 +01:00
|
|
|
mapper-single.c \
|
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 \
|
2018-11-13 07:41:27 +01:00
|
|
|
xfer-options.c \
|
|
|
|
|
xfer-libasound.h \
|
2018-11-13 07:41:28 +01:00
|
|
|
xfer-libasound.c \
|
|
|
|
|
frame-cache.h \
|
|
|
|
|
frame-cache.c \
|
2018-11-13 07:41:29 +01:00
|
|
|
xfer-libasound-irq-rw.c \
|
2018-11-13 07:41:35 +01:00
|
|
|
subcmd-transfer.c \
|
2018-11-13 07:41:40 +01:00
|
|
|
xfer-libasound-irq-mmap.c \
|
|
|
|
|
waiter.h \
|
2018-11-13 07:41:42 +01:00
|
|
|
waiter.c \
|
2018-11-13 07:41:43 +01:00
|
|
|
waiter-poll.c \
|
2018-11-13 07:41:44 +01:00
|
|
|
waiter-select.c \
|
axfer: add support for timer-based scheduling model with MMAP operation
In 2010, ALSA PCM interface got an flag of hardware parameters to suppress
periodical interrupts, according to a request from PulseAudio developer.
In typical PCM operation for usual hardware, PCM drivers configure the
hardware to generate the periodical interrupts to notify that the same
amount of data frames as a period of PCM buffer is actually transferred
via serial sound interface. The flag can suppress this if the driver
support it.
There's some merits of this configuration:
- No interrupt context run for PCM substream. The PCM substream is
handled in any process context only. No need to care of race
conditions between interrupt/process contexts. This is good for
developers of drivers and applications.
- CPU time is not used for handlers on the interrupt context. The CPU
time can be dedicated for the other tasks. This is good in a point
of Time Sharing System.
- Hardware is not configured to generate interrupts. This is good in a
point of reduction of overall power consumption.
Disabling period interrupt is used for 'Timer-based scheduling' to
consume data frames on PCM buffer independently of interrupt context. As
noted, no interrupt context runs for PCM substream, thus any blocking
operation is not released. Furthermore, system calls for multiplexed I/O
is not also released without timeout.
In this scheduling model, applications need to care of available space on
PCM buffer by lapse of time, typically by yielding CPU and wait for
rescheduling. For the yielding, timeout is calculated for preferable
amount of PCM frames to process. This is an additional merit for
applications, like sound servers. when an I/O thread of the server wait
for the timeout, the other threads can process data frames for server
clients. Furthermore, with usage of rewinding/forwarding, applications
can achieve low latency between transmission position and handling
position even if they uses large size of PCM buffers.
But the timeout should be calculated with enough care of hardware
capabilities. To disable period interrupt, used hardware should satisfy
some requirements for data transmission:
1. Even if drivers don't handle interrupts to queue next data transmission,
hardware voluntarily perform the data transmission when needed
(typically by requesting DMA automatically).
2. hardware has a capability to report current position of data
transmission with enough accuracy against the data transmission.
developers refer this as 'granularity'. If hardware can always
reports updated position after the data transmission finishes, the
granularity equals to the size of period of PCM buffer.
3. a fine size of data transmission in one time. This size is decided
depending on configuration of hardware or DMA controller, but for
efficiency it may not be one byte. Thus some amount of data frame is
transferred by one data transmission. Developers refer this as
'burst-ness'.
The timeout should be calculated according to the item 2 and 3, however
in current ALSA PCM interface supplemental information is not delivered
from drivers to applications. Although at present userspace applications
should be written by a speculative way for this point, there's few
problems because there're a few hardware which satisfy the above items.
However, when more drivers supports this feature, the problem may largely
be exposed and bothers application developers.
This commit adds an option to use 'timer-based scheduling' for data
transmission. This commit adds '--sched-model' option, and the scheduling
mode is enabled when 'timer' is assigned to the option by equal sign.
Although there's some TODOs, you can see the scheduling mode in this
simple program, like:
$ axfer transfer --sched-model=timer -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv
$ axfer transfer --sched-model=timer -C -d 2 -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:45 +01:00
|
|
|
waiter-epoll.c \
|
|
|
|
|
xfer-libasound-timer-mmap.c
|
2018-11-13 07:41:47 +01:00
|
|
|
|
|
|
|
|
if HAVE_FFADO
|
|
|
|
|
axfer_SOURCES += xfer-libffado.c
|
|
|
|
|
LDADD += -lffado
|
|
|
|
|
endif
|
2018-12-05 22:31:46 +01:00
|
|
|
|
|
|
|
|
EXTRA_DIST = \
|
|
|
|
|
axfer.1
|