In the commit 38a2d2eda8 ("pcm: dmix: Do not discard slave reported
delay in status result"), the PCM dmix hwptr update code was rewritten
to follow the slave PCM hwptr update. This is based on the similar
change in PCM dshare, the commit faf53c197c.
There was a bug in the commit 38a2d2eda8 regarding the PCM state
change, and it was addressed in commit 3752e6b873 ("pcm: dmix: Fix
the inconsistent PCM state"). However, we've hit yet another bug in
this commit. Namely, the hwptr update was forgotten in the
snd_pcm_dmix_sync_ptr0() function. So the hwptr value passed from
snd_pcm_dmix_status() isn't properly stored, and it screws up at some
long run occasionally.
This patch covers the bug by replacing with the right value.
Fixes: 38a2d2eda8 ("pcm: dmix: Do not discard slave reported delay in status result")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200013
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 38a2d2eda8 ("pcm: dmix: Do not discard slave reported
delay in...") changed the handling in snd_pcm_dmix_status() for taking
the actual delay from the slave PCM status. Along with it, the commit
removed the line to update its own state altogether, as it had been
done originally in the dshare patch (commit faf53c197c "pcm_dshare:
Do not discard slave reported delay..."), supposing that the slave PCM
keeps this same state. However, for dmix/dshare, the PCM state may
differ from the slave, thus these changes resulted in the inconsistent
PCM state.
For dshare, the issue was already addressed by commit ad6957c618
("plugin:dshare: wrong state reporting"), while the fix for dmix was
forgotten until now.
This patch restores the code to set the proper dmix PCM state again
like in the previous versions.
Fixes: 38a2d2eda8 ("pcm: dmix: Do not discard slave reported delay in...")
Reported-by: Cheng Sun <chengsun9@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>
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 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>
In the case of dshare, dsnoop, and dmix when a device is opened twice
and fails the second time, the semaphore is completely discarded. This
creates dangling semaphore data.
This patch removes the possibility for the semaphore to be destroyed during
a typical open failure by first checking if the shared memory can be destroyed
or not. If the shared memory cannot be released it means both it and the
semaphore are still in use and therefore the semaphore is just released.
Signed-off-by: Joshua Frkuska <joshua_frkuska@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
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>
Currently, dmix & co plugins ignore the XRUN state of the slave PCM.
It's (supposedly) because dmix deals with the PCM in a free-wheel
mode, which is equivalent with XRUN. But, this difference (whether
the correct freewheel or XRUN) should be done by the kernel, and we
may have an XRUN state indeed (e.g. via xrun injection).
This patch fixes this lack of behavior, to handle PCM xrun and does
prepare when the slave PCM is in such a state.
Also, the patch consolidates the prepare callback for all dmix, dsnoop
and dshare plugins, and fix/cleanup a bit for dshare/dsnoop codes to
align with dsnoop code.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After suspend and resume, the alsa driver is stopped. But if alsa-lib run
into snd_pcm_xxxx_drain(), it need to wait avail >= pcm->stop_threshold,
otherwise, it will not exit the loop, so finally it is blocked at poll() of
snd_pcm_wait_nocheck(pcm, -1).
This patch is to add state check after snd_pcm_wait_nocheck(pcm, -1), if
the state is SND_PCM_STATE_SUSPENDED, then return error.
Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fetch the timestamp and other status fields by issuing
snd_pcm_status() for the slave PCM. Also, fill the delay field
properly. This should fix longstanding PA's complaints.
Reported-by: Dan Hordern <danhordern@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The current behavior of snd_pcm_rewindable and snd_pcm_forwardable means
that the returned value is only accurate to one period. Or maybe even
meaningless if period interrupts are off. Fetch the up-to-date position
of the hardware pointer, as that's what is wanted by callers.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Such negative values can happen when an underrun happens and xrun
detection is disabled. Another situation is if the device updated the
pointer before alsa-lib has a chance to detect the xrun.
The problem is that these negative values could propagate to the
snd_pcm_rewindable return value, where it is specified that negative
returns must be interpreted as error codes and not as negative amount of
samples.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
There are a few places where the argument of the .rewind or .forward
callback is checked against the same value as returned by .rewindable or
.forwardable. Express this "don't rewind more than rewindable" logic
explicitly, so that the future fixes to the rewindable size can go to
one function instead of two.
While at it, take advantage of the fact that snd_pcm_mmap_avail() cannot
return negative values (except due to integer overflow, which is AFAICS
impossible given the current boundary choice).
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Now all PCM plugins do support the proper timestamp type or pass it
over slaves. The internal monotonic flag is dropped and replaced with
tstamp_type in all places.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
not doing so, leaves the pcm object in an inconsistent state since
'info' field is copied from the slave which is then used when
snd_pcm_hw_params_is_monotonic() is called.
For instance, when using dmix with aplay and an underrun is occuring, the following
info is returned:
underrun!!! (at least 1248687948.256 ms long)
Status:
state : XRUN
trigger_time: 1390347762.628483000
tstamp : 1390347766.184350000
delay : -635
avail : 15687
avail_max : 15675
now is computed from CLOCK_MONOTONIC while pcm status tstamps are from gettimeofday().
After the fix, underruns are still occuring on my setup but at least the displayed info
is correct:
underrun!!! (at least 7630.409 ms long)
Status:
state : XRUN
trigger_time: 7652.739201431
tstamp : 7660.369600636
delay : -624
avail : 15676
avail_max : 15664
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As reported dead-lock, do local lock counting and invoke abort() when
the lock counts do not match at close() time.
Reported-by: <mateen abdulmateen.shaikh@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Added new channel-mapping API functions.
Not all plugins are covered, especially the route, multi and external
plugins don't work yet.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add SETUP state checks and do modifications according latest ALSA driver
(passing wrong event identification).
ALSA bug#4914
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This ensures they are emitted in .data.rel.ro rather than .data.rel,
which should make a nice difference when using prelink.
Signed-off-by: Diego E. 'Flameeyes' Pettenò <flameeyes@gmail.com>
There was a change in alsa-lib 1.0.16 which looks like it was designed to
make dmix skip samples in the case of underruns, but it causes the first
sample to be skipped since dmix->slave_hw_ptr == dmix->slave_appl_ptr.
The following patch fixes this and fixes a small typo in the comment.
From: Mike Gorse <mgorse@mgorse.dhs.org>
The direct plugins have the automatic format-detection feature but it
wasn't enabled properly in the interface. Now you can pass the format
"unchanged" to make the plugin detect a proper format.
This will change the default format of some drivers, such as, HD-audio.
PCM direct plugins didn't update the timestamp properly.
Now it always starts the slave PCM with MMAP tstamp_mode so that the
timestamp will be being updated. When a client is set up as MMAP
tstamp_mode as well, simply copy this slave timestamp. Otherwise
status callback calculates the current timestamp as usual.
This patch causes snd_pcm_dmix_close() to up a semaphore after downing it
if it is unable to discard it. It prevents some deadlock that I am
getting when a couple of applications interact and one of them closes the
device and later re-opens it.
From: Mike Gorse <mgorse@mgorse.dhs.org>
i386/x86_64 alsa-lib may need to handle big-endian formats, e.g.
when running via qemu on PPC. The generic dmix code already has
both endian support, so let's use it as fallback.
Instead of link_fd, more generic callback link_slaves is introduced.
This is called for linking the slave streams as the source to the
given master stream.
