use previously introduced helper function, this commit unifies behavior
of readi and readn
corner case behavior of readi is changed by this commit, previously,
in case 0 bytes were red from file (EOF), frames = 0 was returned,
signaling api user as if no data was red from slave, after the patch,
amount of frames red from slave with data red from slave stored in buffer
is returned when EOF is reached
Signed-off-by: Adam Miartus <amiartus@de.adit-jv.com>
Reviewed-by: Timo Wischer <twischer@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
add helper function to copy input file data to buffer mapped by areas,
in case of an error, do not fill the areas, allowing device read buffer
to be provided to api caller
previously unused rbuf variable is reused for this purpose
Signed-off-by: Adam Miartus <amiartus@de.adit-jv.com>
Reviewed-by: Timo Wischer <twischer@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
purpose of this fix, is to read most accurate timestamps.
From documentation of /src/pcm/pcm.c, we can see:
"""" \par Timestamp mode
The timestamp mode specifies, if timestamps are activated. Currently, only #SND_PCM_TSTAMP_NONE and #SND_PCM_TSTAMP_MMAP modes are known.
The mmap mode means that timestamp is taken on every period time boundary. Corresponding position in the ring buffer assigned to timestamp can be obtained using #snd_pcm_htimestamp() function. """"
As snd_pcm_generic_htimestamp() internally calls snd_pcm_htimestamp() to read time, so accurate timestamp can be read from snd_pcm_generic_htimestamp().
Also, in case of pcm_file, if the underlying slave is hardware, then we would wish to read elapsed hardware time, as it will be the most accurate, as opposed to the elapsed wall time.
This will provide pcm_file with the most accurate timestamps.
Following are the timesamps read with timestamp enabled, for with fix and without fix scenarios:
1> With fix:
:~#time aplay --enable-tstamp -Dhtstamp_test --period-time=5000 -v -fdat /dev/urandom
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
File PCM (file=/tmp/swarate_out.wav)
Final file PCM (file=/tmp/swarate_out.wav)
..
Slave: Hardware PCM card 0 'imx6q-sabresd-wm8962' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 240
period_time : 5000
tstamp_mode : ENABLE
.
.
Before sleep = 142:409.807623
After sleep = 142:409.807623
Before sleep = 142:414.806016 (calling snd_pcm_htimestamp(handle, &avail, &tstamp_before))
sleep of 2 milisec
After sleep = 142:414.806016 (calling snd_pcm_htimestamp(handle, &avail, &tstamp_after)
From the above timestamps, we can see that slave has returned the same timestamps, as --period-time choosen is 5msec.
2> Without this fix:
The timestamps are returned with realtime value.
:~# time aplay --enable-tstamp -Dhtstamp_test --period-time=5000 -v -fdat /dev/urandom
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
File PCM (file=/tmp/swarate_out.wav)
Final file PCM (file=/tmp/swarate_out.wav)
.
.
Slave: Hardware PCM card 0 'imx6q-sabresd-wm8962' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 240
period_time : 5000
tstamp_mode : ENABLE
.
.
Before sleep = 241:136.875845 (calling snd_pcm_htimestamp(handle, &avail, &tstamp_before))
sleep of 2 milisec
After sleep = 241:139.076376 (calling snd_pcm_htimestamp(handle, &avail, &tstamp_after)
We can observe here, the timestamps shows time diff of ~2ms, which is the time gap of sleep duration.
Before sleep = 241:139.617588
After sleep = 241:141.746845
Before sleep = 241:142.291618
After sleep = 241:144.406406
Before sleep = 241:144.951421
After sleep = 241:147.066118
Before sleep = 241:147.623421
After sleep = 241:149.740573
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Mounesh Sutar <sutar.mounesh@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit reverts parts of commit 4081be0b87,
because it is realy useful to use the file plugin in a capture path for
debugging. Also it fixes the truncate issue mentioned in above commit.
Additionally following MMAP access issue is considered:
$ arecord -D teeraw -M -d5 arecord.wav
Recording WAVE 'arecord.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
ALSA lib pcm/pcm_file.c:358:(snd_pcm_file_write_bytes)
write failed: Bad file descriptor
ALSA lib pcm/pcm_file.c:358:(snd_pcm_file_write_bytes)
write failed: Bad file descriptor
arecord: pcm/pcm_file.c:397: snd_pcm_file_add_frames:
Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.
Aborted by signal Aborted...
Signed-off-by: Timo Wischer <twischer@de.adit-jv.com>
Signed-off-by: Mounesh Sutar <sutar.mounesh@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Plugin file provides no private hw_ptr and appl_ptr but instead links
them to the slave pcm. If the slave pcm itself changes its hw_ptr or
app_prt this needs to be done in file plugin, too.
Plugin 'plug' is such a candidate changing the hw_ptr and app_ptr in
hw_params call dependent on the automatically inserted plugins. ALSA
unfortunately has no support for automatically updating chained
pointers.
A notification on pointer change seems to be prepared inside the
snd_pcm_set_ptr() routine via rbptr->changed(), but it is not (yet)
implemented so that we need to care for it manually.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit f8d07a7354.
The htimestamp field was already intiailized. It was just overlooked,
sorry.
Suggested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
PCM operation htimestamp is not implemented in plugin file.
Calling snd_pcm_htimestamp() on a plugin file crashes. This scenario
is considered now.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Joshua Frkuska <joshua_frkuska@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Traditionally, many of ALSA library functions are supposed to be
thread-unsafe, and applications are required to take care of thread
safety by themselves. However, people never be careful enough, and
almost all applications fail in this regard.
This patch is an attempt to harden the thread safety in exported PCM
functions in a simplistic way: just wrap some of exported functions
with the pthread mutex of each PCM object. Not all API functions are
wrapped by the mutex since it doesn't make sense. Instead, the
patchset covers only the functions that may be likely called
concurrently. The supposedly thread-safe API functions are marked in
the document.
For achieving the feature, two new fields are added snd_pcm_t when the
option is enabled: thread_safe and lock. The former indicates that
the plugin is thread-safe that doesn't need this workaround and the
latter is the pthread mutex. Currently only hw plugin have
thread_safe=1. So, the most of real-time sensitive apps won't be
influenced by this patchset.
Although the patch covers most of PCM ops, a few snd_pcm_fast_ops are
left without the extra mutex locking: namely, the ones that may have
blocking behavior, i.e. resume, drain, readi, writei, readn and
writen. These are supposed to handle own locking in the callbacks.
Also, if anyone wants to disable this new thread-safe API feature, it
can be still turned off via --disable-thread-safety configure option.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now all PCM plugins do support the proper timestamp type or pass it
over slaves. The internal monotonic flag is dropped and replaced with
tstamp_type in all places.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 1d80c5b901 message describes
behaviour in case of specified infile option as
'No file writes will take place in this case'.
But this is clearly not the case as output file gets truncated while
running `arecord -Dtestin >/dev/null`, where "testin" is defined as
pcm.testin {
type file
slave.pcm null
file "/tmp/qqqq.out"
infile "/tmp/qqqq.in"
format "raw"
}
Besides that, the existing behaviour is rather counterintuitive,
requiring both output and input files to exist and making access to them
regardless of playback or capture intention.
Also, it's very confusing to get output file truncated while trying to
just capture from the device.
Current changeset introduces the following behaviour:
- output file ("file" option) is only (p)open()'ed for writing
only on playback to the device
- any data is written to the output file descriptor
(provided with "file" option) only on playback to the device
- input file ("infile" option) is only open()'ed for reading only on
capture from the device
- any data is read from the input file descriptor
(provided with the "infile" option) only on capture from the device
Signed-off-by: Andrey Mazo <mazo@telum.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Valgrind report for this leak was:
Command: aplay -Dfile:'/tmp/qqq',raw qqq.wav
14 bytes in 1 blocks are definitely lost in loss record 1 of 2
at 0x402BF5C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
by 0x40D7557: snd_pcm_file_hw_params (in /usr/lib/libasound.so.2.0.0)
by 0x40BA093: _snd_pcm_hw_params_internal (in /usr/lib/libasound.so.2.0.0)
by 0x40AB831: snd_pcm_hw_params (in /usr/lib/libasound.so.2.0.0)
by 0x804C523: ??? (in /usr/bin/aplay)
by 0x804E5B7: ??? (in /usr/bin/aplay)
by 0x804FC8C: ??? (in /usr/bin/aplay)
by 0x80520FB: ??? (in /usr/bin/aplay)
by 0x4184942: (below main) (libc-start.c:226)
Signed-off-by: Andrey Mazo <mazo@telum.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 5c5f135812 requires both file and
infile options to be missing to report a failure.
In fact, only file option is mandatory and should be checked there.
Otherwise, NULL file triggers segfault in
snd_pcm_file_replace_fname() called from
snd_pcm_file_open_output_file().
infile option is optional, so don't report fatal error if it's missing.
Signed-off-by: Andrey Mazo <mazo@telum.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix the call of _snd_pcm_hw_params() to _snd_pcm_hw_params_internal().
The build passed wrongly because of _snd_pcm_hw_params define.
Having the same function name as the struct name is is simply
confusing...
Also, to be sure, _snd_pcm_hw_params is undef'ed in pcm_local.h, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Added new channel-mapping API functions.
Not all plugins are covered, especially the route, multi and external
plugins don't work yet.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
* added support for including pcm stream params in the output filename
* added support for piping the stream to a shell command if the filename
string starts with a pipe char
Signed-off-by: Pavel Hofman <pavel.hofman@insite.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This ensures they are emitted in .data.rel.ro rather than .data.rel,
which should make a nice difference when using prelink.
Signed-off-by: Diego E. 'Flameeyes' Pettenò <flameeyes@gmail.com>
By doing this we move them from the .data section to .rodata setion,
or from .data.rel to .data.rel.ro.
The .rodata section is mapped directly from the on-disk file, which is
always a save, while .data.rel.ro is mapped directly when using
prelink, which is a save in a lot of cases.
Signed-off-by: Diego E. 'Flameeyes' Pettenò <flameeyes@gmail.com>
When ifile option is used for the file plugin, it ignores the slave PCM
and just feeds the input data.
This patch changes the behavior a bit - it uses the slave PCM as the
timing source (just read and throw data away) so that the input data
can be read in the right sample rate.
Addeed a new option "truncate" to indicate the behavior of creating
the output file. When it's true (the default), the file is overwritten
and truncated at creation. When false, the plugin tries to open a
unique file with a number suffix.
The global behavior of "file" and "tee" PCMs is defined via
defaults.pcm.file_truncate option. You can overwrite it in ~/.asoundrc.
Instead of link_fd, more generic callback link_slaves is introduced.
This is called for linking the slave streams as the source to the
given master stream.
safe_strtoll() now accepts numbers in any base. It formerly assumed that
its input was a decimal number, which had the consequence that
hexadecimal or octal numbers would be parsed as strings when occurring
outside of parameter lists.
This obsoletes some workarounds in the file permission parsing code that
relied on this bug.
When this new parameter is specified, the behavior of opening a file PCM
for input is changed to the following: reads from the device, instead of
being passed down to the slave PCM, will read the raw data from the
specified file. No file writes will take place in this case. In the
absence of this parameter, previous behavior is unchanged.
The input file name and descriptor are kept in the snd_pcm_file_t struct
in a manner analogous to the already existing output file parameter.
TODO:
(1) Only interleaved reads (snd_pcm_file_readi) have been implemented
for now.
(2) File read()'s that return a number of bytes that's not a multiple of
the frame size will result in data loss (choppiness). The rbuf,
rbuf_size_bytes, and rbuf_used_bytes members of the snd_pcm_file_t
struct will be used to address this problem in the future.
(3) Mind whether the PCM was opened in blocking mode. If so, we'll have
to loop until the buffer has been filled with read()'s.
Signed-off-by: Juan Carlos Castro y Castro <jcastro@vialink.com.br>
Initialize wbuf_used_bytes, adjust appl_ptr in the rewind and forward
callbacks, and adjust the offset when a data block straddles the
boundary of the wbuf buffer.
Fixed the bug producing silent tones with some combinations of plugins.
The internal buffer handling is now better (cleaner) integrated with
snd_pcm_generic_*().
