Regardless of success/failure mapping of control/status data for runtime of
PCM substream, appl_ptr/avail_min parameters are initialized. In current
implementation, they are initialized in case-dependent, different places.
It's possible to collect them to one place.
This commit unifies relevant code in a place after all of trials for the
mappings are finished.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Handling mapping operation for status/control data includes some
supplemental operations for fallback mode. It's better to have helper
functions for this purpose.
This commit adds the helper functions.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There is a call of snd_pcm_set_appl_ptr() in snd_pcm_hw_hw_params()
only for the capture direction. This must be a leftover from the
ancient code. Although it's harmless for now, it's superfluous and
confusing. Let's kill it.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When error occurs, return value from ioctl(2) is -1 and error code can
be got thread local variable, errno. It's OK just to check the return
value without any assignment.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A function, snd_pcm_hw_open_fd(), is just for internal use. This function
has an obsoleted parameter and we can remove it without any compatibility
issue.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
I noticed that some plugin codes have no proper PCM state checks and
it results in expected outcomes. For example, when snd_pcm_drain() is
called for a dmix PCM after calling snd_pcm_drop(), it stalls
unexpectedly. It's just because its drain callback doesn't expect the
SND_PCM_SETUP state.
We can fix such a bug in each place one by one, but a safer way would
be to filter out all such cases commonly in the PCM API functions
themselves. This patch adds the PCM state sanity checks to major API
functions so that they return -EBADFD when called in the unexpected
PCM states.
As well as for the thread-safety extension, it'd be a question of the
performance; again at this time, the hw PCM is considered as an
exception, and it has pcm->own_state_check flag set, which means that
the common PCM state checks are skipped.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The newly added locking code seems to have confused quite a few
people, as "thread_safe=1" may be considered as if the thread-safety
lock has to be turned on. (It meant that the plugin _is_ thread-safe,
i.e. it needs no extra locking.)
For avoiding such a misunderstanding, this commit renames the relevant
pcm fields and give more comments to explain what is for what.
The former single pcm->thread_safe flag is now split to two boolean
flags, pcm->need_lock and pcm->lock_enabled. It consumes a few more
bytes, but this would be (hopefully) better understandable.
No functional change by this commit.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both of alloca() and automatic variables keeps storages on stack, while
the former generates more instructions than the latter. It's better to use
the latter if the size of storage is computable at pre-compile or compile
time; i.e. just for structures.
This commit obsolete usages of alloca() with automatic variables.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both of alloca() and automatic variables keeps storages on stack, while
the former generates more instructions than the latter. It's better to use
the latter if the size of storage is computable at pre-compile or compile
time; i.e. just for structures.
This commit obsolete usages of alloca() with automatic variables.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both of alloca() and automatic variables keeps storages on stack, while
the former generates more instructions than the latter. It's better to use
the latter if the size of storage is computable at pre-compile or compile
time; i.e. just for structures.
This commit obsolete usages of alloca() with automatic variables.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both of alloca() and automatic variables keeps storages on stack, while
the former generates more instructions than the latter. It's better to use
the latter if the size of storage is computable at pre-compile or compile
time; i.e. just for structures.
This commit obsolete usages of alloca() with automatic variables.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit applies code format according to typical and moderate rule,
for snd_pcm_hw_change_timer().
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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>
This commit fixes below compiler warnings.
pcm_hw.c: In function ‘_snd_pcm_hw_open’:
pcm_hw.c:1816:16: warning: ‘err’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return err;
^
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This header isn't used in these files, so stop trying to include it.
This helps builds on systems that don't provide the header (such as
Android/Bionic).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
use STATUS_EXT ioctl if PCM protocol is > 2.0.12
All audio timestamp configuration will be ignored with an
older protocol.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The current behavior of snd_pcm_rewindable and snd_pcm_forwardable means
that the returned value is only accurate to one period. Or maybe even
meaningless if period interrupts are off. Fetch the up-to-date position
of the hardware pointer, as that's what is wanted by callers.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Such negative values can happen when an underrun happens and xrun
detection is disabled. Another situation is if the device updated the
pointer before alsa-lib has a chance to detect the xrun.
The problem is that these negative values could propagate to the
snd_pcm_rewindable return value, where it is specified that negative
returns must be interpreted as error codes and not as negative amount of
samples.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
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>
This patch implements the support for sw_params timestamp type in PCM
hw layer. As gettimestamp() is still unchanged, the resultant
timstamps may be still with CLOCK_MONOTONIC even if you pass monotonic
raw type. More fixes will follow.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On most HDA Intel HDMI devices, the channel map list is approx. 500 ints
in size, making the 256-sized buffer used by
snd_pcm_query_chmaps_from_hw() too small and causing the query to fail
(NULL result to caller, ENOMEM).
Bump the buffer size to 2048 ints.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We can't calculate memory storage in bytes, when we're supposed
to store ints in it!
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
These fields are not used, and their name similarity to other
fields are quite confusing when trying to debug alsa-lib.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Instead of keeping modified asound.h and asequencer.h, copy the files
in the kernel include/uapi/sound as is, and give some renames for
avoiding conflicts with alsa-lib's definitions.
Some structs, unions and typedefs in asound.h and asequencer.h are
once renamed in local.h before inclusion, then renamed back again.
A bonus by this action is that some local codes don't have to refer to
sndrv_xxx any longer. However, some codes like src/seq/seq.c need
explicit cast because of unavoidable conflicts of struct types.
Another significant change is that now snd_pcm_sw_params.period_event
field is removed. Instead, try to access the last reserved field
internally.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of a single channel map, multiple channel maps can be provided
in a form of compound (array) to hw and null plugins. In null
get_chmap, the channel map corresponding to the current channels is
copied from the given channel maps.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a config definition "chmap" to override (or enhance) the channel
maps. So far, only a single channel map can be provided, and the
channel count consistency isn't strictly tested at all.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a function similar like snd_pcm_query_chmaps() but performs
the query without a PCM handle. The card, device and substream
numbers are passed as well as stream direction.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of passing ambiguous integer array, define snd_pcm_chmap_t and
snd_pcm_chmap_query_t so that user can understand more easily which
element is for what.
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>
Dan McCombs discovered that snd_pcm_close() invocations are not leading
to associated timers being closed, which results in successively more
timers being created but not freed.
Original patch from Daniel T Chen <crimsun@ubuntu.com>.
BugLink: https://bugs.launchpad.net/bugs/451893
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
As the result of snd_pcm_delay() is affected not only by hw_ptr
and appl_ptr, but also by 'runtime->delay' property,
either SNDRV_PCM_IOCTL_DELAY or SNDRV_PCM_IOCTL_STATUS ioctl
must be used to get the correct result.
Previously 'runtime->delay' was ignored in case 'hw->sync_ptr'
was used.
Signed-off-by: Kai Vehmanen <kvehmanen@eca.cx>
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>
The plug PCM copies the 'mode' field from the slave PCM. If blocking mode is
enabled for the plug PCM the mode is subsequently overwritten with the original
requested 'mode'. If non-blocking mode is requested this does not happen.
Because the hw PCM synthesizes the 'mode' from the actual file descriptor flags
no SND_PCM_NO_xxx will ever be set for it. This has the effect that the 'mode'
of the plug PCM will also not include those flags anymore -- unless they are
overwritten as mentioned above. This basically means SND_PCM_NO_xxx is ignored
for plug:hw:4711 style device strings opened in non-blocking mode.
You can easily test this with "aplay --channels 7 --disable-channels -f S16_LE
-r 44100 -D plug:hw:0" on a device that cannot do 7 channels. Normally this
call should fail, however if you add "-N" to the command line this call will
succeed.
This patch simply copies the SND_PCM_NO_xxx flags back into the 'mode' field in
case we don't overwrite it with the original anyway.
Probably closes bug 3571 for good.
From: Lennart Poettering <mznyfn@0pointer.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Two trivial compile warning fixes:
- Add a missing return to snd_pcm_hw_clear_timer_queue()
- params->info is no long but int
The second one might have hit already on 64bit machine, but alas,
no one didn't notice it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
