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>
The recent fix commit [8985742d91: pcm: dmix: Handle slave PCM xrun
and unexpected states properly] caused a regression in dmix and other
plugins regarding suspend/resume. For example, aplay endlessly prints
"Suspended. Trying resume. Done." message if suspend and resume are
performed in the middle of playback.
The reason is that the commit above changed the shadow PCM state
(dmix->state) to SUSPENDED when the slave PCM is in suspend, while it
doesn't restore the shadow state upon resume. Thus it appears as if
it's always suspended even after the resume is invoked.
The fix is just to add the proper update of the shadow state in
snd_pcm_direct_resume().
Reported-by: Shengjiu Wang <shengjiu.wang@freescale.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both, min_dB and max_dB, are floating type whereas the TLV is (always)
unsigned.
The problem with the conversion of a negative floating-point number into an
unsigned integer is, that the behavior is undefined. This may, depending on
the platform, result in a wrong TLV, i.e. for the default values of min_dB
(-51dB) and max_dB (0dB), alsactl generates the following state on an ARM
cpu build with GCC:
control.1 {
iface MIXER
name Master
value.0 255
value.1 255
comment {
access 'read write user'
type INTEGER
count 2
range '0 - 255'
tlv '00000001000000080000000000000014'
dbmin 0
dbmax 5100
dbvalue.0 5100
dbvalue.1 5100
}
}
With the fix applied, alsactl stores the correct TLV:
control.1 {
iface MIXER
name Master
value.0 255
value.1 255
comment {
access 'read write user'
type INTEGER
count 2
range '0 - 255'
tlv '0000000100000008ffffec1400000014'
dbmin -5100
dbmax 0
dbvalue.0 0
dbvalue.1 0
}
}
Also tested for different combinations of min_dB and max_dB other than the
default values.
Replaces:
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107733.html
Fixes:
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107628.html
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
dmix and other PCM plugins tries to open a secondary stream with
O_APPEND flag when the shmem was already attached by another.
However, when another streams have been already closed after the
shmem check, this open may return the error EBADFD, since the kernel
accepts O_APPEND only for the secondary streams.
This patch adds a workaround for such a case. It just retries opening
the stream as the first instance (i.e. without O_APPEND flag).
This is basically safe behavior (the kernel takes care of races), even
we may do this even unconditionally. But it's bad from the
performance POV, so we do it only when really needed.
Reported-by: Lars Lindqvist <lars.lindqvist@yandex.ru>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When snd_pcm_mmap_commit() return error, the appl pointer is also updated.
which cause the avail_update()'s result wrong.
This patch move the snd_pcm_mmap_appl_forward() to the place when
snd_pcm_mmap_commit() is successfully returned.
Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As stated in manpage SHMCTL(2), shm_nattch is "No. of current attaches"
(i.e., number of processes attached to the shared memeory). If an
application uses alsa-lib and invokes fork() from a thread of the
application, there may be the following execution sequence:
1. execute the following statement:
pcm_direct.c:110: dmix->shmptr = shmat(dmix->shmid, 0, 0)
(shm_nattch becomes 1)
2. invoke fork() in some thread.
(shm_nattch becomes 2)
3. execute the following statement:
pcm_direct.c:122: if (buf.shm_nattch == 1)
4. execute the following statement:
pcm_direct.c:131: if (dmix->shmptr->magic != SND_PCM_DIRECT_MAGIC)
(As stated in manpage SHMGET(2), "When a new shared memory segment
is created, its contents are initialized to zero values", so
dmix->shmptr->magic is 0)
5. execute the following statements:
pcm_direct.c:132: snd_pcm_direct_shm_discard(dmix)
pcm_direct.c:133: return -EINVAL
The above execution sequence will cause the following error:
unable to create IPC shm instance
This error causes multimedia application has no sound. This error rarely
occurs, probability is about 1%.
More notes about this patch:
this patch tries to address the race above by changing the condition
to identify "the first user". Until now, the first user was
identified by checking shm_nattch. But this is racy, as stated in the
above.
In this version, we try to assign a shm at first without IPC_CREAT.
If this succeeds, we are not alone, so we must not be the first user.
Only when this fails, try to get a shmem with IPC_CREAT and IPC_EXCL.
If this succeeds, we are the first user. And, one more notable point
is that the race of this function call itself is protected by
semaphore in the caller side. The only point to avoid is the race
after shmget() and the first initialization, and this method should
work around that.
Signed-off-by: Qing Cai <bsiice@msn.com>
Signed-off-by: Qing Cai <caiqing@neusoft.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some systems, like Android/Bionic, do not support SysV at all.
Let the configure script detect if the header is available, and
if not, automatically disable the pieces that require it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
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>
If you build with --disable-pcm, the rawmidi code fails to link because
it uses the page_size helper declared in local.h, but the page_* funcs
are in the pcm mmap module. Move these funcs into conf.c so that they
are always available to the rest of the system.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
