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.
sbase.c:327:16: warning: variable ‘values’ set but not used [-Wunused-but-set-variable]
unsigned long values;
^
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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 commit fixes below compiler warnings.
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;
^
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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++)
^
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
CC: pulseaudio-discuss@lists.freedesktop.org
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a UCM configuration for the rt5645 codec on Intel's Cherry-Trail
platform. Tested on the Microsoft Surface 3.
Signed-off-by: Stephen Just <stephenjust@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Fixes: 147093ac5b8d('test: Add pcm-multi-thread program')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
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>
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.
This commit fixes the bug.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits, APIs to add an element set are changed, while a test
program for user-defined element set doesn't follow them.
This commit add support the change.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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>
Second argument of these functions has three different names in
documentation/header/code (obj/control/value). This easily causes users'
confusion.
This commit applies consistent names for the arguments.
Fixes: 90020c05f8 ('ctl: improve comments for handling element data')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is really just nitpick, but it annoyed me for a few seconds, so I thought
I'd just fix it.
In d7534b2cee (hgcompile -> gitcompile) the filename was updated but
INSTALL was not, leaving outdated docs.
Signed-off-by: Henrik Austad <henrik@austad.us>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA ctl feature includes threshold level feature. This is introduced in
2006, and there's little resources about it.
This commit adds a simple explanation about the feature.
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>
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.
[1] http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/core?id=cab2ed7474bffafd2a68a885e03b85526194abcd
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
This commit do it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds a description about the design of ALSA control interface
for developers to understand a few components of low level.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit a192f52fc6 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.
Fixes: a192f52fc6 ("conf/ucm: ROCKCHIP-I2S: add Rockchip I2S UCM config.")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
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 PCM namehint for some PCM types like dmix, dsnoop and surround51
should be defined as single directional.
Reported-by: Trent Reed <treed0803@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Reported-by: Trent Reed <treed0803@gmail.com>
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>
Taken from the ChromeOS sources, this configuration was tested on Veyron
Jerry based Chromebook from Google.
[Added missing Makefile changes by tiwai]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.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>
