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>
Because of the way the pcm_read() functions are currently used, returning
rcount or result is equivalent but I feel it is more accurate to
return 'result'.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It is required (exclude the fatal SIGABRT) to call snd_pcm_close() and
the end of work (outside of the interrupt handler). Use new snd_pcm_abort()
function to inform alsa-lib to not ignore EINTR and move the in_aborting
variable to the global scope to be checked in the i/o loops.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
When aplay/arecord are called without any argument the application hangs forever.
Instead of hanging, print the usage and exit.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now aplay tries to follow the given channel map by rearranging the
channels even when the channel map override isn't allowed but if the
device is still capable to return a channel map.
Also update the man page appropriately.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
With -m option, user can specify the order of channel map.
As of this commit, it just tries to override the channel map, thus it
works only on devices that support the channel map override like HDMI.
Adjusting the channel order in aplay itself will be added later.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
AC_SYS_LARGEFILE in configure.in will automatically set up defines so
that open() will support large files if supported, and if not, this
allows us to fall back gracefully to non-LFS open().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dumping HW parameters of the current device with snd_pcm_hw_params_dump,
a new option --dump-hw-params added.
Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BugLink: https://bugs.launchpad.net/bugs/816388
Reported-by: Chad Dunlap <cldunlap1@gmail.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
aplay is limited to 32 channels, which makes it impossible to use it for
testing devices with more channels. here we increase the limit to 256,
which should be sufficient for a virtual device made of 4 64-channel
soundcards.
Signed-off-by: Tim Blechmann <tim@klingt.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The recent addition of pause/resume control via keyboard brought
a problem when aplay/arecord is invoked in background. For avoiding
regressions, it's safer to use non-interactive mode as default and
enable the new feature via an option.
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The term_c_lflag variable might be unitialized in some cases. Add extra
check to avoid setting of wrong value.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
