When a duration is specified but the the capture device cannot use the
requested sample rate and an alternative rate is used the duration
sample count must be (re)calculated.
Fixes: https://github.com/alsa-project/alsa-utils/pull/200
Signed-off-by: Tj <hacker@iam.tj>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
- ERESTART not supported platform: use EINTR instead
- add include/os_compat.h, well-used OS specific definition
- copied include/bswap.h from alsa-lib
- EPIPE and ESTRPIPE are different usage, but currently
EPIPE is used when ESTRPIPE is not defined.
To fix this problem, assign ESPIPE instead.
Fixes: https://github.com/alsa-project/alsa-utils/pull/186
Signed-off-by: SASANO Takayoshi <uaa@uaa.org.uk>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Also replace lseek64 with lseek.
_FILE_OFFSET_BITS=64 is passed to needed platforms since configure uses
AC_SYS_LARGEFILE macro. Therefore off_t is already 64-bit and lseek is
same as lseek64.
Additionally this fixes buils with latest musl where these lfs64
functions are moved out from _GNU_SOURCE and under _LARGEFILE64_SOURCE
macro alone. This makes the builds fail on 32-bit platforms even though
default off_t on musl is 64-bit always.
Fixes: https://github.com/alsa-project/alsa-utils/pull/183
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
WAV_FMT_EXTENSIBLE header contains valid bits per sample, which can be
different than bits per sample. Make sure it is taken into account when
parsing headers and choosing playback format.
BugLink: https://github.com/alsa-project/alsa-utils/pull/178
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The code origin comes from me. Unfortunately, it was merged
by mistake to another commit. Remove it for now.
Fixes: https://github.com/alsa-project/alsa-utils/issues/153
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The commit 4b959a4 ("aplay: Fix for arecord recording ghost data")
intruduced a regression (file may contain more samples than
expected). Correct this.
Fixes: https://github.com/alsa-project/alsa-utils/issues/163
Fixes: 4b959a4 ("aplay: Fix for arecord recording ghost data")
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
When recording we should only write the amount of data read to output
file instead of copying whole buffer. This fixes glitches appearing at
the end of recorded file, when stopping recording.
Fixes: https://github.com/alsa-project/alsa-utils/pull/150
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Remove the call to snd_config_expand_custom() to expand the top-level
input config. And replace it with calls to snd_config_evaluate_string()
for each non-compound config while processing individual objects. This
will allow retreving variable definitions from object attribute values
and global definitions.
Add a new field "current_obj_cfg" to hold the current object config
being pre-processed.
This will facilitate adding simple math expressions for computing
attribute values for objects based on other attributes. For ex: we can
set the expression for buffer size as follows:
buffer_size "$[($in_channels * 48) * 4]"
The buffer_size attribute value will be computed with the attribute
value "in_channels" based on the expression above. So if $in_channels =
2, buffer_size will be evaluated to 384.
Additionally this change also permits computing attribute values based
on previously computed values. For example:
buffer_size "$[($in_channels * 48) * 4]"
dma_buffer_size "$[$buffer_size * 2]"
dma_buffer_size will be computed as 768. Note that the order of
definitions for buffer_size and dma_buffer_size matters because the
evaluation for dma_buffer_size depends on the evaluation of buffer_size.
In order to conform to this, the tplg_object_copy_and_add_param() is
modified to add attribute configs from class config to an object using
snd_config_before() instead of snd_config_add().
With this change, we no longer need to set the auto_attr_updater for
buffer type widget objects. So remove it.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The return value from abs() for the most negative integer is
undefined. Cap it properly for the 32bit sample handling.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The handling of 16bit samples in the peak calculations has a bug when
a sample with 0x8000 is passed. As abs() treats 32bit int, it returns
0x8000. And yet the code stores back into 16bit value again.
To fix that overflow, use 32bit value (i.e. val instead of sval) for
the further calculations.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When we reverted 0c5948e ("aplay: try to use 16-bit format to
increase capture quality"), we should also handle the original
problem somehow. This code shows a warning with a hint to
the right parameter.
Fixes: https://github.com/alsa-project/alsa-utils/issues/96
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Terminating stream with CTRL-C will set in_aborting flag which is used to leave any
write/read loop on the ALSA device.
After ending the read/write loop aplay tries to drain the stream which is not required and can also lead to malfunctions:
-If user interrupts a blocked/non responsive PCM (e.g. usb uac2 gadget which does not consume data
due to stream stopped by host) it will successfully terminate the write loop but will hang again in drain call.
This would require to hit CTRL-C again to unblock which should be avoided.
Aplay currently anyhow allows signal handler to get invoked only once.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Use the standard poll mechanism to ensure that there's
something in the input to avoid busy loop on the file
descriptor with the non-block mode set.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Recently users reported a bug, I tested it and found it is a common
issue on Laptop or Desktop machines.
The issue is users plug a headset and use "arecord test.wav" to
record a sound with default input volume, the recorded sound has
poor quality and nearly can't distinguish it is the sound we want
to record.
This is because the input volume is low and the default format is U8.
The driver records sound with 16bit, because the input volume is low,
most of samples are within (-256,+256), when converting 16bit to U8,
those samples will be 0x7f. This is called quantization noise and we
could only workaround it by increase the input volume or adding -f to
arecord.
But users want to record a better quality sound with default input
volume (after installing a new OS, the volume is the default volume),
and they don't want to add parameters to the arecord because most of
new linux users just use "arecord test.wav".
So this patch tries to change the default format from U8 to S16_LE/BE.
If the machine doesn't support S16_LE/BE, it still uses U8 as default
format.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The count argument was renamed to samples to correctly represent
the value meaning. Also, remove the wrong count recalculation lines
for 16-bit, 24-bit and 32-bit samples.
BugLink: https://github.com/alsa-project/alsa-utils/issues/57
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Fix a minor typo for the '-f cdr' description.
Fixes: 55cd025f18 ("aplay -- update the man file")
BugLink: https://github.com/alsa-project/alsa-utils/pull/34
From: YetAnotherNerd <YetAnotherNerd@users.noreply.github.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This patch changes the way aborted stream is being saved. Currently when
abort signal happens the write back of read samples is skipped but there
is no reason to not save them. Also, we need to know how much frames have
been read and write only those.
Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This patch changes the logic of pcm_read() when abort signal has been
detected. During such condition we should return the amount of frames
actually read instead of the size requested by caller.
Currently functions pcm_read() and pcm_readv() when aborted (in_aborting
flag set) return the amount of requested frames instead of those actually
read prior to interrupt. The consequence of this is repetition of recent X
frames where X stands for amount of frames in one period. This problem is
barely visible or rather audible when the period is small like few
milliseconds because repetition of 1 [ms] of data is not-noticeable
however if we use buffer and period sizes in seconds then the problem
becomes apparent.
Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This patch changes the logic of pcm_readv() when abort signal has been
detected. During such condition we should return the amount of frames
actually read instead of the size requested by caller.
Currently functions pcm_read() and pcm_readv() when aborted (in_aborting
flag set) return the amount of requested frames instead of those actually
read prior to interrupt. The consequence of this is repetition of recent X
frames where X stands for amount of frames in one period. This problem is
barely visible or rather audible when the period is small like few
milliseconds because repetition of 1 [ms] of data is not-noticeable
however if we use buffer and period sizes in seconds then the problem
becomes apparent.
Example issue -> thesofproject/sof#3189
Signed-off-by: Marcin Rajwa <marcin.rajwa@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The pointer operand to the binary `+` operator must be to a complete
object type.
Signed-off-by: Michael Forney <mforney@mforney.org>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
They are equivalent, but __func__ is in C99. __FUNCTION__ exists only
for backwards compatibility with old gcc versions.
Signed-off-by: Michael Forney <mforney@mforney.org>
Reviewd-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While the progress bar cannot be negative, GCC concludes that it can be
and assumes tmp can be written past the end. Fixes this GCC warning:
aplay.c:1747:18: warning: '%02d' directive writing between 2 and 11 bytes
into a region of size 4 [-Wformat-overflow=]
1747 | sprintf(tmp, "%02d%%", maxperc[c]);
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It also reduces compiled size slightly.
aplay.c: In function 'capture':
aplay.c:3055:34: error: '-01' directive output may be truncated writing 3
bytes into a region of size between 1 and 4097 [-Werror=format-truncation=
]
3055 | snprintf(namebuf, namelen, "%s-01", buf);
| ^~~
aplay.c:3055:4: note: 'snprintf' output between 4 and 4100 bytes into a
destination of size 4097
3055 | snprintf(namebuf, namelen, "%s-01", buf);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
aplay.c:3053:34: error: '-01.' directive output may be truncated writing 4
bytes into a region of size between 1 and 4097 [-Werror=format-truncation=
]
3053 | snprintf(namebuf, namelen, "%s-01.%s", buf, s);
| ^~~~
aplay.c:3053:4: note: 'snprintf' output 5 or more bytes (assuming 4101)
into a destination of size 4097
3053 | snprintf(namebuf, namelen, "%s-01.%s", buf, s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
aplay.c:3065:34: error: '%02i' directive output may be truncated writing
between 2 and 10 bytes into a region of size between 0 and 4096 [-Werror=
format-truncation=]
3065 | snprintf(namebuf, namelen, "%s-%02i", buf, filecount);
| ^~~~
aplay.c:3065:30: note: directive argument in the range [1, 2147483647]
3065 | snprintf(namebuf, namelen, "%s-%02i", buf, filecount);
| ^~~~~~~~~
aplay.c:3065:3: note: 'snprintf' output between 4 and 4108 bytes into a
destination of size 4097
3065 | snprintf(namebuf, namelen, "%s-%02i", buf, filecount);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
aplay.c:3063:34: error: '%02i' directive output may be truncated writing
between 2 and 10 bytes into a region of size between 0 and 4096 [-Werror=
format-truncation=]
3063 | snprintf(namebuf, namelen, "%s-%02i.%s", buf, filecount, s);
| ^~~~
aplay.c:3063:30: note: directive argument in the range [1, 2147483647]
3063 | snprintf(namebuf, namelen, "%s-%02i.%s", buf, filecount, s);
| ^~~~~~~~~~~~
aplay.c:3063:3: note: 'snprintf' output 5 or more bytes (assuming 4109)
into a destination of size 4097
3063 | snprintf(namebuf, namelen, "%s-%02i.%s", buf, filecount, s);
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
setup_chmap() will return with error number if hw_map calloc fail or
channels doesn't match with hw_params, but memory free was ignored when
error occurs.
Signed-off-by: chunxu.li <chunxuxiao@gmail.com>
Reviewed-by: Takashi Sakamoto o-takashi@sakamocchi.jp
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Either '--samples' ('-s') and '--duration' ('-d') option is available
exclusively, according to its semantics and actual implementation.
This commit improves description of manual at this point.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Daniel Baluta daniel.baluta@nxp.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A '--samples' ('-s') option was added so that record/playback process is
terminated after handling the same number of PCM frames as a value of the
option. However this option is not described in aplay manual.
This commit adds a paragraph for the option.
Fixes: 3d44e2bc15 ('aplay: Add samples argument for playing/recording a given number of samples')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Daniel Baluta daniel.baluta@nxp.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A '--sleep-min' option was already obsoleted for aplay. On the other hand,
a paragraph for the option was left as is.
This commit deletes the paragraph.
Fixes: 4cb74aed89 ('Remove sleep_min from aplay')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Daniel Baluta daniel.baluta@nxp.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
aplay tries to check the file size via fstat() at parsing the format
headers and avoids parsing when the size is shorter than the given
size. This works fine for regular files, but when a special file like
pipe is passed, it fails, eventually leading to the fallback mode
wrongly.
A proper fix is to do this sanity check only for a regular file.
Reported-by: Jay Foster <jay@systech.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On my 32 bit armhf board arecord exits because of write() returning EFBIG
when the output file size reaches 2147483647 bytes.
To fix this, include generated header file before system header files
so that _FILE_OFFSET_BITS=64 is used properly, as required in documentation
"man feature_test_macros".
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There are number of devices that support up to 384 kHz sampling rate and
some devices up to 768 kHz sampling rate. This patch increases sanity
check limit to 768k in order to support testing of such hardware.
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This fixes a bug when trying to play files with size
smaller than maximum supported header size.
Lets have a look at the following example:
$ aplay -s 2 sample.raw
-> playback_go(fd = 10, loaded = 26, count = 2, name="sample.raw")
--> l = loaded = 26
--> c = count - written = 2
--> c -= l = 2 - 26 = -24
---> r = safe_read(fd, audiobuf + 26, -24)
---> r = -1, EXIT_FAILURE
In this case we have already 'loaded' from the input file more
bytes that we need to send to pcm device. So, we need to adjust
the number of bytes loaded and avoid reading a negative number
of bytes.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
