Both of alloca() and automatic variables keep 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.
Both of alloca() and automatic variables keep 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.
Both of alloca() and automatic variables keep 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.
Both of alloca() and automatic variables keep 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.
mixer: include library local header to find layout of structures
Inner this library, implementation of each features can find actual layout
of structures by including local header. Although, mixer feature is written
without the header and as the same way for applications. This brings some
inefficiencies such as usage of alloca() to keep memory objects for the
structures.
This commit includes the header for further improvements in mixer
feature.
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.
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.
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.
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.
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.
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.
conf: remove alloca() from snd_func_private_pcm_subdevice()
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.
conf: remove alloca() from snd_func_pcm_args_by_class()
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
pcm: remove alloca() from snd_pcm_query_chmaps_from_hw()
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.
pcm: remove alloca() from snd_pcm_hw_change_timer()
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.
pcm: remove alloca() from _snd_pcm_hook_ctl_elems_install()
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.
pcm: remove alloca() from snd_pcm_direct_set_timer_params
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.
pcm: remove alloca() from snd_pcm_direct_initialize_poll_fd()
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.
pcm: remove alloca() from snd_pcm_direct_initialize_slave
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.
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.
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.
ctl: add compatibility information for snd_ctl_elem_info_set_dimension()
I forgot it when committing to the API.
Fixes: 16812b70daeb('ctl: add an API to set dimension levels to element information') 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.
Takashi Iwai [Thu, 30 Jun 2016 15:24:42 +0000 (17:24 +0200)]
pcm: Remove home brew atomic operations
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.
Takashi Iwai [Thu, 30 Jun 2016 13:32:40 +0000 (15:32 +0200)]
pcm: Add thread-safety to PCM API
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.
pcm_direct.c: In function ‘snd1_pcm_direct_prepare’:
pcm_direct.c:821:2: warning: enumeration value ‘SND_PCM_STATE_PREPARED’ not handled in switch [-Wswitch]
switch (snd_pcm_state(dmix->spcm)) {
^
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;
^
In file included from ../../include/local.h:165:0,
from tplg_local.h:17,
from data.c:20:
data.c: In function ‘tplg_parse_tuples’:
../../include/error.h:64:21: warning: ‘id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define SNDERR(...) snd_lib_error(__FILE__, __LINE__, __FUNCTION__, 0, __VA_ARGS__) /**< Shows a sound error message. */
^
data.c:576:14: note: ‘id’ was declared here
const char *id;
^
topology: apply the same type to compared two variables
This commit fixes below compiler warnings.
data.c: In function ‘get_token_value’:
data.c:262:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < tokens->num_tokens; i++) {
^
data.c: In function ‘copy_tuples’:
data.c:351:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < tuples->num_sets ; i++) {
^
data.c:378:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j = 0; j < tuple_set->num_tuples; j++) {
^
data.c: In function ‘tplg_free_tuples’:
data.c:723:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < tuples->num_sets; i++)
^
data.c: In function ‘get_tokens’:
data.c:276:6: warning: unused variable ‘err’ [-Wunused-variable]
int err = 0;
^
data.c: In function ‘has_tuples’:
data.c:302:6: warning: unused variable ‘err’ [-Wunused-variable]
int err = 0;
^
hctl: remove assertion from element event handler because removal event overwrites all of queued events
In ALSA control core, when several events occurs for an element, they're
represented bit mask (struct snd_ctl_event.data.elem.mask). Thus userspace
applications can handles these events separately in one I/O operation.
There's an exception; removal event. This is represented by all of bits in
the mask. Therefore, when a removal event occurs for an element, all of
queued events for the element are overwritten.
This works worse for a combination of applications which add/remove control
elements and applications which keep a cache of elements. For example,
let's assume a case that:
1.some elements are added by ioctl(SNDRV_CTL_IOCTL_ELEM_ADD).
2.ALSA control core handles the request and queues 'add' event.
3.applications don't read the event yet.
4.the elements are removed by ioctl(SNDRV_CTL_IOCTL_ELEM_REMOVE)
5.ALSA control core handles the request and queues 'removal' event by
overwriting queued events.
6.applications read the event at last.
7.the applications cannot find removed elements in their cache data.
Especially, when applications use hctl interface of ALSA userspace library,
this situation occurs because the interface is designed to keep element
cache implicitly inner the library. PulseAudio is such an application. When
executing a test program of ALSA library (test/user-ctl-element-set.c),
pulseaudio process aborts due to assertion at calls of
snd_hctl_handle_events().
The rule to represent events is in ALSA kernel/userspace interfaces
(UAPI header) and it's difficult to improve the rule. Therefore,
developers should pay enough attention to the fact that userspace
applications can receive removal events for elements which are not
notified with 'add' event.
For this reason, this commit removes assertion from event handler of ALSA
hctl API.
ctl: improve documentation of APIs to add an element set
Currently, documentation of APIs to add an element set describes causes of
errors partly. But it gives an opinion to describe them thoroughly. This
is not good for users.
This commit changes the documentation so that it partly describes the
causes.
test: add linker flag with pthread for pcm-multi-thread stress test
This test program is a pthread application, while Makefile has no flags
for linker about pthread library. This can cause below error.
$ make pcm-multi-thread
CCLD pcm-multi-thread
/usr/bin/ld: pcm-multi-thread.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:523: recipe for target 'pcm-multi-thread' failed
make: *** [pcm-multi-thread] Error 1
This commit fixes the bug by adding a corresponding flag.
Linux 4.7 or former have no validator of dimension information. This can
causes an issue related to user-defined element set. For example, When
calculated total members in multi-dimensional matrix is larger than actual
capacity of snd_ctl_elem_value_t, processes to handle the element can
cause buffer-over-run.
For backward portability of this userspace library, this commit adds a
validator of dimension information. When userspace applications give
invalid dimension information to APIs to add element set, they receive
-EINVAL.
A simple multi-thread stress test for PCM is added to test
subdirectory. It can perform various PCM update function in the
worker threads while reading/writing the data in the main thread.
It can help catching the unexpected error or blockage. For example,
running the capture test with a softvol plugin will lead to the assert
due to the races.
ctl: fix a test for user-defined element set in a point of dimension
Currently, this test program has a bug related to dimension information.
When testing an element set with byte type, the program adds 512 members
to an element. This is a maximum number permitted for this type.
On the other hand, dimension information of the elements consists of
[8, 4, 8, 4]. Calculated members in the multi-dimensional matrix is 1024.
This should be less than 512.
Takashi Sakamoto [Wed, 29 Jun 2016 13:43:03 +0000 (22:43 +0900)]
ctl: support dimension test for user-defined element set
In former commits, APIs to add an element set are extended to support extra
fields to information structure. Currently, the fields are mainly used to
describe dimension level.
This commit adds tests to check the dimension level.
Takashi Sakamoto [Wed, 29 Jun 2016 13:43:01 +0000 (22:43 +0900)]
ctl: optimize a test for user-defined element set to older kernels
In Linux 4.0 or former, call of ioctl(2) with SNDRV_CTL_IOCTL_ELEM_ADD
doesn't fill all of identical information in an argument; i.e. numid.
With the kernel, a test of user-defined element set fails.
This commit fixes the bug. The 'numid' field in identical information
is always zero when adding an element set, therefore zero check has an
effect.
Takashi Sakamoto [Wed, 29 Jun 2016 13:43:00 +0000 (22:43 +0900)]
ctl: add an API to set dimension levels to element information
In a former commit, 'struct snd_ctl_elem_info' is used as a 'container' to
transfer extra fields of element information for APIs to add an element
set. The extra fields should be filled in advance of call of the APIs.
Currently, dimension level is in the extra fields and no APIs to set it.
This commit adds an API to set dimension level to the information
structure. This API is expected to be used in advance of usage of APIs
to add an element set, for nothing others. When the information structure
is extended in future, then the similar APIs shall be added for the new
feature.
Takashi Sakamoto [Wed, 29 Jun 2016 13:42:59 +0000 (22:42 +0900)]
ctl: support extra information to user-defined element set
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.
Takashi Sakamoto [Mon, 27 Jun 2016 14:37:36 +0000 (23:37 +0900)]
ctl: use automatic variable instead of call of alloca(3)
Inner this library, layouts of all structures are public. At a compilation
time, each size of the structures can be calculated. It means that we can
use automatic variable instead of calling alloca(3) to program this
library because in both ways storages are kept on stack frame of process
VMA. Besides, the usage of automatic variables requires less instructions
than calls of alloca(3). Furthermore, alloca(3) is not described in any
C language standards.
This commit replaces calls of alloca(3) just for structures with automatic
variables, for control features.
Takashi Sakamoto [Mon, 27 Jun 2016 13:02:57 +0000 (22:02 +0900)]
ctl: fix returning zero for dimension level 4
In ALSA kernel/userspace interfaces, 'struct snd_ctl_elem_info' has a
'dimension' parameter. This parameter consists of an array with four
elements. Each element represents the number of members in corresponding
dimension level to construct matrix.
In current implementation, a get function, 'snd_ctl_elem_info_get_dimension()'
is hardcoded to return zero to level 4, against actual value. This commit fixes
the bug.
Takashi Sakamoto [Fri, 17 Jun 2016 12:26:42 +0000 (21:26 +0900)]
ctl: add test program for control element set
The feature of control element set has been abandoned for a long time since
firstly introduced in 2003. Furthermore, there's few applications to utilize
this feature. These situations bring a hard work to persons who need the
feature. Especially, a lack of test program make it harder to fix much bugs
in this feature.
This commit adds a test program as a sample of the feature. This program
adds element sets of each element type to 'hw:0' in this order; boolean,
integer, enumerated, bytes, IEC958 and integer64. Each iteration includes
below scheme:
1. add an element set with 900 elements. Each of them has maximum number
of members allowed by ALSA ctl core.
2. check all of events generated by above operation.
3. retrieve information of each element, then validate it.
4. unlock each member of all elements because they're initially locked.
5. write to all of members in all elements and read.
6. check all of events generated by above operation.
7. write information for threshold level to the element set and read it.
8. check all of events generated by above operation.
9. remove the element set.
10.check all of events generated by above operation.
When any of these operations fail, it means regression occurs. Then, added
elements still remain in a certain sound card. In this case, unloading
drivers corresponding to the card is an easy way to recover.
Besides, this program doesn't perform below element operations of ALSA ctl
feature:
- list
- lock
- replace
Takashi Sakamoto [Wed, 15 Jun 2016 14:57:44 +0000 (23:57 +0900)]
ctl: improve API documentation for threshold level operations
In alsa-lib, threshold level operations require an array of unsigned-int
members, while there's little explanation about how to fill it. To usual
developers such as me, they're quite hard to understand.
This commit adds a few comment for easy understanding about how to use
the APIs.
Takashi Sakamoto [Wed, 15 Jun 2016 14:57:41 +0000 (23:57 +0900)]
ctl: change former APIs as wrapper functions of element set APIs
In former commit, userspace library gets some APIs for element set. Some
existed functions can be simple wrappers of them.
This commit changes these APIs as wrapper functions. Additionally, this
commit also adds local variables for identical information of elements.
This modification is important to keep API consistency.
Some old APIs to add an element have id variables with const type
qualifier, while some new APIs to add element set changes the content of
given parameters. This comes from a change in Linux kernel 4.1.
In this commit [1], in-kernel implementation fills all fields of identical
data in userspace. As a result, when adding a new element set, userspace
applications can get an identical data for the first element in the set.
This lost the semantics of const type qualifier in userspace.
Takashi Sakamoto [Wed, 15 Jun 2016 14:57:40 +0000 (23:57 +0900)]
ctl: improve comments for API to add an element of IEC958 type
In ALSA control core, it's not allowed to an element set of IEC 958 type
to have several elements. Therefore, consecutive patchset doesn't touch an
API to add an element of IEC958 type. However, it's better to supplement
comments for the API.
Takashi Sakamoto [Wed, 15 Jun 2016 14:57:39 +0000 (23:57 +0900)]
ctl: add functions to add an element set
ALSA control core allows userspace applications to add an element set.
However, in ALSA userspace library, there's no APIs enough to utilize
the feature. The library has APIs just to add an element set with a single
element.
This commit adds functions to add an element set with several elements.
Takashi Sakamoto [Wed, 15 Jun 2016 14:57:38 +0000 (23:57 +0900)]
ctl: improve comments for handling element data
Some parts of control API documentation are described with core-developer
friendly explanations. To usual developer such as me, they're quite hard
to understand.
This commit improves such comments for a part of APIs to handle data of
each element.
Heiko Stübner [Wed, 8 Jun 2016 23:17:15 +0000 (01:17 +0200)]
conf/ucm: ROCKCHIP-I2S: rename to VEYRON-I2S
Commit a192f52fc63a introduced an ucm profile for Rockchip Veyron-
Chromebooks by taking the ucm profile from the ChromeOS userspace.
But similarly to DAISY-I2S, PAZ00 and most other profiles, the audio
setup is pretty specific to a board type, so hogging the Rockchip name
will make it harder for future Rockchip based boards to fit in nicely.
And while Veyron also is a family of boards, all of them share the
same audio setup. The ucm profile was not released with any official
alsa release and the audio setup also isn't in the mainline kernel yet,
so such a rename should be easily possible.
Eliot Miranda [Wed, 1 Jun 2016 06:16:31 +0000 (08:16 +0200)]
async: Handle previously installed signal handler
The issue is with the signal handler installed and deinstalled in
alsa-lib async handler. This code makes no attempt to remember any
previously installed signal handlers for SIGIO, if SIGIO is used.
Consequently it does not call any previous handlers from its own
handler once installed, and does not reinstall any previous handler
when deinstalling its handler. Consequently, use of also-lib within
applications that depend on SIGIO will break those applications,
rendering them inoperative once alsa-lib is running because their
signal handlers are no longer called.
This patch does remember and restore any previous handler, and chains
calls to the handler if it exists.
Takashi Iwai [Wed, 25 May 2016 13:03:51 +0000 (15:03 +0200)]
pcm: dmix: resume workaround for buggy driver
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.
Takashi Iwai [Sat, 28 May 2016 08:37:26 +0000 (10:37 +0200)]
pcm: Fix secondary retry in dsnoop and dshare
The commit [fdba9e1bad8f: 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.
Takashi Iwai [Wed, 18 May 2016 08:38:27 +0000 (10:38 +0200)]
pcm: Remove resume support from dmix & co
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>
Takashi Iwai [Tue, 17 May 2016 13:39:07 +0000 (15:39 +0200)]
conf: Add thread-safe global tree reference
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.
Takashi Iwai [Thu, 12 May 2016 14:30:44 +0000 (16:30 +0200)]
namehint: Don't enumerate as duplex if only a single direction is defined
When a hint description has only either device_input or device_output,
we shouldn't handle it as a full duplex but rather a single
direction. In that way, we can avoid to list up a playback stream
like dmix or surround51 as a capture stream in the namehint.
Takashi Iwai [Wed, 11 May 2016 11:06:25 +0000 (13:06 +0200)]
pcm: dmix: Fix doubly resume of slave PCM
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.
Takashi Iwai [Wed, 11 May 2016 07:06:47 +0000 (09:06 +0200)]
pcm: Fix suspend/resume regression with dmix & co
The recent fix commit [8985742d91db: 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>
Jörg Krause [Sun, 8 May 2016 18:48:42 +0000 (20:48 +0200)]
pcm: softvol: fix conversion of TLVs min_db and max_dB value
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:
Mengdong Lin [Fri, 29 Apr 2016 03:03:45 +0000 (11:03 +0800)]
topology: Update PCM configurations in Broadwell text conf file
To make this conf file a better example, update the name & ID of PCMs
(front-end DAI link) and their cpu DAI (front-end DAI), same as those
defined by Broadwell upstream driver.
Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
git://git.alsa-project.org / alsa-lib.git / log