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>
This introduces read_header function which tries
to read the header of an audio file in order to determine
its type.
This has the following effects:
(1) makes code easier to read
(2) don't abort if file size is less than expected header
(2), allows us to play small files with size smaller than any
supported audio file headers.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-s --samples allows aplay to be used for playback/capture a given
number of samples per channel
Signed-off-by: Ion-Horia Petrisor <ion-horia.petrisor@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix bug in arecord --max-file-time where the file size could overflow
32 bits.
Signed-off-by: Scott Gilliland <scott.gilliland@gatech.edu>
Acked-by: John Sauter <John_Sauter@systemeyescomputerstore.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Write can return less then requested bytes, but we treat this as
an error thus ending up with confusing error messages.
Fix this by introducing xwrite helper, which makes sure all bytes
are written or an error is returned.
With this patch an usecase where disk is filled by recording will
print:
$ /mnt/msc/audio.wav: No space left on device
instead of random messages like:
$/mnt/msc/audio.wav: No such file or directory
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If PCM is paused and then we do system supend-resume, the stream throws
error(EBADF) when stream is paused released.
Check the pcm state before pause/release and if stream is suspended,
call snd_pcm_resume to resume the stream.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If -d was given to arecord while commit
8aa13eec80 (now reverted) was in effect,
the last read would be shorter than the chunk size, but pcm_read would
read and return the chunk size, the samples were discarded, and
capture() continued in a loop because count never reached 0. arecord
opens a new file each loop iteration, if arecord is dynamically naming
files, --use-strftime option or beyond the wave 2GB limit, this will
generate a series of header only wave files. If the file is unique
the originally recorded data is lost and it will continue overwriting
the same file with a header only wave file.
While the current pcm_read can't fail (it can exit), it is better to
just fix this lurking bug in case it is "fixed" again.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
when a user enters a command, he expects his command to be executed
as specified or aborted if it is impossible to fulfill his request
right now a command like "arecord -d hw:1,0 --max-file-time 1h recording.wav"
will happily record something and exit without error status while the resulting
recording contains definitely not what the user requested
to fix this, the patch handles the number parsing function's error channel
and checks whether the parsed number has any trailing characters
Signed-off-by: erwin <nebelbank@posteo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When recording or playing back audio in a format where the number of
significant bits is less than the physical width (e.g. S24_LE), the VU
meter code needs to consider the number of significant bits in the samples
rather than the physical sample width (e.g. 24 vs 32 bits). Otherwise the
resulting VU meter display will be far too low and it will just indicate
0% all the time.
Tested with a device supporting the S24_LE format.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
arecord removes a file before writing into it. It's not
appropriate in some cases. For example, if you a pass
a symlink to a file, then the symlink will be removed
while the user expects to record into the symlink's target.
Another case is recording into the device file. Some
modems provide a tty device file as a voice device.
And it's not possible to write into it under root with
arecord, because it removes the device file.
So check the type of a file before writing into it and
remove only regular files.
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When aplay is invoked to play from stdin, it can't be terminated by
normal signals like SIGTERM or SIGINT. It's because our signal
handler tries to trap as much as possible while the stalling point is
not in the PCM loop but rather the file I/O.
For fixing this, leave our signal handler once when a signal is
received and snd_pcm_abort() is called. At the next hit, it shall be
handled normally.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 8aa13eec80.
The semantics for pcm_read() and pcm_readv() was changed, but the
callers expect the exact frame count as requested. It's possible
to fix callers, but the fix is more complicated than to revert the
change. Note that '-d' processing was broken in some cases.
Note: The reverted commit allows that the return value might be
greater than requested (see the first condition in read routines).
Commit 6bbeb78d forgot to change some of VU-meter output to stderr.
This patch makes the output of `aplay -vvv` consistent again.
Signed-off-by: Sergey <sergemp@mail.ru>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
