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>
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>
On snd_pcm_drain() the slave PCM driven via plugin DSHARE is not filled with
silence. Result is endless playback of buffer content until pcm is closed.
In ALSA pcm dshare plugin, called do_silence method to fix the issue.
Signed-off-by: Anant Agrawal <Anant_Agrawal@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the case of dshare, dsnoop, and dmix when a device is opened twice
and fails the second time, the semaphore is completely discarded. This
creates dangling semaphore data.
This patch removes the possibility for the semaphore to be destroyed during
a typical open failure by first checking if the shared memory can be destroyed
or not. If the shared memory cannot be released it means both it and the
semaphore are still in use and therefore the semaphore is just released.
Signed-off-by: Joshua Frkuska <joshua_frkuska@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_pcm_dshare_status() gets the underlying status from the slave PCM.
This may contain a delay value that includes elements such as codec and
other transfer delays. Use this as the base for the returned delay
value, adjusted for any frames buffered locally (within the dshare
plugin).
Note: snd_pcm_dshare_delay() is not updated.
Signed-off-by: Alan Young <consult.awy@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Otherwise, they will linger after the error is returned (but pcm->setup == 0).
Then, if the caller tries to clean up and call snd_pcm_close(), the assertion
plug->gen.slave == plug->req_slave will fail.
Signed-off-by: Michael Forney <mforney@mforney.org>
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>
Easily seen when two threads try at the same time, one of them will fail.
The bug was identified by using apulse with Skype.
Fixes: dec428c352 ("pcm: fix 'unable to create IPC shm instance' caused by fork from a thread")
Fixes: https://github.com/i-rinat/apulse/issues/38
Signed-off-by: Ismael Luceno <ismael@iodev.co.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In this development period, some APIs have already been added. Most of
them are to add an element set, while their names are not so appropriate
against their feature. This is due to following to names of old APIs.
This commit renames them.
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_softvol_open().
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 softvol_load_control().
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>
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>
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_direct_set_timer_params().
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_direct_initialize_poll_fd().
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_direct_initialize_slave().
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_get_params().
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_set_params().
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits for thread-safe PCM APIs, snd_pcm_ioplug_sw_params() got
0 as its return value, against the original implementation.
This commit fixes it.
Fixes: 54931e5a5455('pcm: Add thread-safety to PCM API')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits for thread-safe PCM APIs, snd_pcm_status() lost its
return value.
This commit regain it.
Fixes: 54931e5a5455('pcm: Add thread-safety to PCM API')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For making the debugging with any deadlocks by the newly introduced
thread-safety feature, add a check with LIBASOUND_THREAD_SAFE
environment variable. When this variable is set to "0", alsa-lib PCM
forcibly disables the whole thread-safe pthread mutex calls.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We've had a few home brew atomic operations in a couple of places in
the PCM code. This was for supporting the concurrent accesses, but in
practice, it couldn't cover the race properly by itself alone.
Since we have a wider concurrency protection via mutex now, we can get
rid of these atomic codes, which worsens the portability
significantly.
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>
rmb() is still left in the code without any actual meaning there just
before the atomic operation. Let's clean it up.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In ALSA control feature, information of an element includes extra fields
to type-specific parameters; i.e. dimension. The fields can be extended in
future.
Meanwhile, current APIs to add user-defined element set can not support
such an extended fields. This may cause inconveniences in future.
This commit supports the fields, by changing APIs for element set.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In previous commit, some APIs to add a single element are discouraged to
continue using.
This commit replaces usage of the old APIs with new APIs.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A slave PCM in OPEN or DISCONNECTED state can't be used properly at
all, so the best option is to return -EBADFD error.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The previous commit removed the whole handling of resume in dmix, but
this seems causing another regression; some buggy drivers assume that
the device-resume needs to be triggered before transitioning to
PREPARED state. As an ugly workaround, in this patch, when the slave
PCM supports resume, snd_pcm_direct_resume() does resume of the slave
PCM but immediately drop the stream after that. In that way, the
device is brought to the sane active state, then the apps can prepare
and restart the stream properly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit [fdba9e1bad: pcm: Fallback open as the first instance for
dmix & co] introduced a mechanism to retry the open of slave PCM for
the secondary streams, but this also introduced a regression in dsnoop
and dshare plugins: since the retry goto-tag was placed at a wrong
position, it retries to re-fetch the shm unnecessarily and eventually
leads to the fatal error.
The bug can be easily reproduced by starting arecord and killing it
via SIGKILL, then starting arecord again. The second arecord fails.
The fix is obviously to move the wrong retry goto-tags to the right
positions.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
PCM dmix and other plugins inherit the resume behavior from the slave
PCM. However, the resume on dmix can't work reliably even if the
slave PCM may do resume. The running state of each dmix stream is
individual and may be PREPARED or RUN_PENDING while the slave PCM is
already in RUNNING. And, when the slave PCM is resumed, the whole
samples that have been already mapped are also played back, even if
the corresponding dmix stream is still in SUSPENDED. Such
inconsistencies can't be avoided as long as we manage each stream
individually.
That said, dmix & co can't provide the proper resume support "by
design". For aligning with it, we should drop the whole resume code
and clear the PCM SND_PCM_INFO_RESUME flag.
Reported-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Most of open functions in alsa-lib have the call pattern:
snd_config_update();
return snd_xxx_open(x, snd_config, ...);
This means that the toplevel config gets updated, and passed to a
local open function. Although snd_config_update() itself has a
pthread mutex to be thread safe, the whole procedure above isn't
thread safe. Namely, the global snd_config tree may be deleted and
recreated at any time while the open function is being processed.
This may lead to a data corruption and crash of the program.
For avoiding the corruption, this patch introduces a refcount to
config tree object. A few new helper functions are introduced as
well:
- snd_config_update_ref() does update and take the refcount of the
toplevel tree. The obtained config tree has to be freed via
snd_config_unref() below.
- snd_config_ref() and snd_config_unref() manage the refcount of the
config object. The latter eventually deletes the object when all
references are gone.
Along with these additions, the caller of snd_config_update() and
snd_config global tree in alsa-lib are replaced with the new helpers.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The dmix plugin and co may trigger the resume for each instance in
snd_pcm_direct_resume(). It means that the slave PCM gets resumed or
re-prepared/started by each opened dmix stream, and this may end up
with the doubly triggers even though the slave PCM has been already
resumed by another dmix stream.
For avoiding this conflicts, check the slave PCM state and resume only
when it's still in the suspended state. Meanwhile we keep the shadow
state updated no matter whether the slave was triggered or not.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
