The fast_ops callback invocation must always pass the fast_op_arg
as the pcm argument. Plugins expect that.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
due to undefined reference to 'environ' error, ucm_exec.c uses workaround.
Fixes: https://github.com/alsa-project/alsa-lib/pull/250
Signed-off-by: SASANO Takayoshi <uaa@uaa.org.uk>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The check of slave PCM state is always done before the client's
recoveries count check, so let's merge them to the common helper.
Also rename the helper function to snd_pcm_direct_check_xrun() as it's
checking both slave and client states now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The current resume handling in PCM direct plugins don't treat multiple
clients properly: once after the slave PCM gets resumed by one
client, the access from others at a later point is seen as already
running although the internal state isn't updated and becomes
inconsistent. This may end up a negative size, which eventually hangs
up.
This patch is an attempt to improve the handling for resume. Now the
suspended state is treated similarly like XRUN; namely, we keep the
slave PCM "recoveries" count that is modified at each time the slave
PCM XRUN happens, so that we can check the inconsistency against the
client's state. As a differentiation to XRUN, we set the highest bit
of recoveries count when the slave stream hits SUSPENDED state. This
bit is referred at comparing with clients, and the client's state is
updated to either XRUN or SUSPENDED depending on this bit.
Along with this change, the actual resume is done in
snd_pcm_direct_slave_recover(), and snd_pcm_direct_resume() rather
calls this internally.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Change the snd_pcm_direct_client_chk_xrun() function to return the
current XRUN state via an error code instead of the state change.
This allows the caller more straightforwardly returning its error, and
also covers the case where XRUN has been set but the function gets
called twice.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix and cleanup snd_pcm_direct_check_interleave() function.
Add requested / hardware channel check and use goto when the interleaved
Fixes: https://github.com/alsa-project/alsa-lib/issues/117
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The recently reported (but a long-standing) bug about the
unconditional semaphore usage in the dmix implies that basically we've
had no problem with the locking in the practical usages over years.
Although the lockless operation has a clear merit, it's a much higher
CPU usage (especially on some uncached pages), and it might lead to a
potential deadlock in theory (which is hard to reproduce at will,
though).
This patch introduces a new configure option "--enable-lockless-dmix"
or "--disable-lockless-dmix" to let user choose the default dmix
operation mode. The usage of the lockless mixing has been already
conditionally enabled via asoundrc and card config
"direct_memory_access", so we just need to set the default value based
on it.
In this patch, the default is set off to the lockless mixing, i.e. the
generic mixing is chosen. It makes more sense from the performance
POV. For any users who still require the lockless operation, it can
be enabled either via configure option or the asoundrc.
The magic number used in the shmem is also changed depending on the
operation mode. It's just for safety, not to conflict both operation
modes with each other.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Feature 'variable periodsize' allows to extend user period size up to
buffer_size/2 independent of slave period. On enlargement of the settings
for period_time.max and period_size.max the setting for openmax
was not updated.
This lead to the effect, that if the slave period itself had openmax
set it was still set on the extended size. Configuration of a period
matching half buffer size was thus rejected.
Example for failure: period size of 384 (half buffer size) is requested
which is rejected and rounded down to 352:
PERIOD_SIZE: [32 352]
BUFFER_SIZE: [64 768]
When correctly applying the openmax setting:
PERIOD_SIZE: [32 384]
BUFFER_SIZE: [64 768]
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
In pcms using direct plugins (dmix/dsnoop/dshare), the timestamp type could
be different from the terminating hw plugin, then the kernel driver.
Be sure such pcms have plugins using consistently the same timestamp type.
signed-off-by: Sylvain Bertrand <sylvain.bertrand@legeek.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This change adapt the fix commit 6b058fda9d
("pcm: dmix: Add option to allow alignment of slave pointers")
for dsnoop plugin
Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr
is not period aligned. Therefore snd_pcm_wait() will block for a longer
time as required.
With these rcar driver changes the exact position of the dma is returned.
During snd_pcm_start they read hw_ptr as reference, and this hw_ptr
is now not period aligned, and is a little ahead over the period while it
is read. Therefore when the avail is calculated during snd_pcm_wait(),
it is missing the avail_min by a few frames.
An additional option hw_ptr_alignment is provided to dsnoop configuration,
to allow the user to configure the slave application and hw pointer
alignment at startup
Signed-off-by: Vanitha Channaiah <vanitha.channaiah@in.bosch.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move the code snd_pcm_direct_reset_slave_ptr() from pcm_dmix.c
to pcm_direct.c and its header so that the helper function can be
re-used by other direct-pcm plugins.
There is no change in the behavior or the functionality.
Signed-off-by: Vanitha Channaiah <vanitha.channaiah@in.bosch.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These changes are required due to the kernel
commit 07b7acb51d283d8469696c906b91f1882696a4d4
("ASoC: rsnd: update pointer more accurate")
Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr
is not period aligned. Therefore snd_pcm_wait() will block for a longer
time as required.
With these rcar driver changes the exact position of the dma is returned.
During snd_pcm_start they read hw_ptr as reference, and this hw_ptr
is now not period aligned, and is a little ahead over the period while it
is read. Therefore when the avail is calculated during snd_pcm_wait(),
it is missing the avail_min by a few frames.
An additional option hw_ptr_alignment is provided to dmix configuration,
to allow the user to configure the slave application and hw pointer
alignment at startup
[ Slight indentation and parentheses removals by tiwai ]
Signed-off-by: Laxmi Devi <Laxmi.Devi@in.bosch.com>
Signed-off-by: Timo Wischer <twischer@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The multiply defined versioned symbols have to be called with
INTERNAL() wrapper.
Add the missing declarations of versioned timer API functions in the
local header, and use them in the callers in PCM.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According POSIX[1] and linux manpage[2] the include is poll.h, not
sys/poll.h.
This fixes the he following compiler warning when build with musl libc:
/usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
#warning redirecting incorrect #include <sys/poll.h> to <poll.h>
^~~~~~~
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A function, snd_pcm_hw_open_fd(), is just for internal use. This function
has an obsoleted parameter and we can remove it without any compatibility
issue.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 1a9bd0f044 ("pcm: direct: Fix for sync issue on xrun
recover") introduced a new field "recoveries" in
snd_pcm_direct_share_t. Unfortunately this caused two issues:
- It changed the size of the struct which is used as the magic key
- The struct size differs between 32bit and 64bit due to alignment
The former brought the incompatibility with the older alsa-lib,
e.g. when you run an app with an older alsa-lib via LD_PRELOAD, it
doesn't work any longer.
The latter is more serious, it disallows running 32bit apps dmix with
64bit together.
As a workaround, put recoveries field to the unused field
"s.xfer_align", so that the struct is in an old form. This makes the
dmix again binary-compatible with 1.1.3 and older versions, and also
fix the incompatibility between 32/64 bits.
This is a one-time workaround, and we may need to reconsider more
about a breakage in future...
Fixes: 1a9bd0f044 ("pcm: direct: Fix for sync issue on xrun recover")
Reported-and-tested-by: Cheng Sun <chengsun9@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently added variable period-size feature for dmix & co seems
causing a regression on some old applications; e.g. Audacious aborts
with an error:
ALSA error: snd_pcm_hw_params_set_buffer_time_near failed: Invalid argument.
As a quick fix, disable the feature as default. One can still enable
it via asoundrc.
Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1033179
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_timer handling is racy: plugins clear timer queue if avail_min
is not reached to force a sleep on timer. The race can happen if
the expected event arrives in between the avail check and the
clearing of pending events. If this race happens, the user will
unnecessarily wait for one more timer event. On low latency/realtime
streams this can lead to xruns and must be avoided.
As a fix we recheck avail after having cleared poll events.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Mounesh Sutar <sutar.mounesh@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The dmix plugin has some optimized implementations for x86 using the
direct memory accesses, which was rather the original version, in
addition to the "generic" implementation using the semaphore
blocking. The x86 implementation relies on the memory coherency *and*
the fast read/write on it.
For other architectures, this has been always disabled just because of
memory coherency. But, the recent LPE audio development revealed
that, even on x86 platforms, the read/write performance might become
extremely bad when the buffer is marked as uncached. Some drivers
already know the buffer is uncached, we need to switch to the generic
mode in such a case.
This patch introduces yet another flag to dmix configuration,
direct_memory_access, that indicates whether the x86-specific
optimization can be used or not. Each driver can set the flag in its
cards config namespace, and the default dmix config refers to it.
As of this patch, only HDMI LPE Audio driver sets it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change in PCM direct plugins to check XRUN in
poll_descriptors callback caused a regression; as consequence, the
whole playback hangs up.
The culprit is a mutex dead lock by the call in snd_pcm_state() inside
the new snd_pcm_direct_poll_descriptors(). The poll_descriptors code
path is protected with pcm mutex, thus an unlocked version
(__snd_pcm_state()) has to be used inside the callback instead.
Fixes: 789ee39727 ("pcm: direct: check state before enter poll on timer")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To avoid the chances of timeout, we need to check the enter poll
in state xrun.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Mounesh Sutar <mounesh_sutar@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If using very short periods, DSHARE/DSNOOP/DMIX may report underruns while in
status 'prepared'. This prohibits correct recovery. Now slave xrun conditions
for DSHARE/DSNOOP/DMIX are being handled properly.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Joshua Frkuska <joshua_frkuska@mentor.com>
Signed-off-by: Mounesh Sutar <mounesh_sutar@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This issue depends on system load - if the process using dshare is
scheduled fast enough, then there is no noise. A delay of e.g >~2ms
produces hearable noise.
Reproduction with instrumented aplay(sleep every 100th period for a
given time):
During the sleep time of 2000000us (2s) the hardware plays old samples
in a loop before xrun is detected and recovered after the sleep.
This is resolved by placing it in silence, in case of dshare plugin.
Signed-off-by: Alexander Jahn <ajahn@de.adit-jv.com>
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch allows the effective period size to be a multiple of the
slave-pcm period size.
Allowing only exact multiple of original period size is achieved by
borrowing code from the kernel hwrules implementation.
This patch is intended to save cpu workload when for example, the
slave operates with very small periods but a user does not need that
small periods.
This feature is enabled by default and can be disabled by adding
config option 'var_periodsize 0'.
Signed-off-by: Alexander Jahn <ajahn@de.adit-jv.com>
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
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>
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>
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>
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>
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>
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>
