The parent hw_ptr may be in another range (boundary limit).
Set the correct value for the caller.
BugLink: https://github.com/alsa-project/alsa-lib/issues/155
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Currently shared memory pointer is initialized to 0 and set to -1
in some, but not in all error paths.
In cleanup path of open the shm pointer is only compared to be non-NULL
before dereferencing it which leads to SEGFAULT in case it was set to -1.
This patch initializes pointer to -1 to have a unique identification
for invalid pointer and also checks for pointer being not -1 on
access in cleanup path.
Signed-off-by: Vanitha Channaiah <vanitha.channaiah@in.bosch.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
A snd_pcm_status() call for the direct plugins receives the status
from the slave PCM, but this doesn't contain a valid appl_ptr, since
the slave PCM for the direct plugins is in a free-wheel mode, hence
the appl_ptr is always zero. This result in the inconsistent
status->appl_ptr and pcm->appl.ptr, hitting the recently introduced
assert() call.
Fix it by transferring the plugin's appl_ptr to the upper caller.
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1181194
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Unfortunately, we cannot use status->avail from slave, because this value
does not wrap to the buffer size and it may even overflow slave boundary
(endless run). We can use only hw_ptr from slave.
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>
allow opening the device and start the audio clock without blocking
any channel
this is required if the audio clock has to be available all the time,
even when application is not streaming audio data
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Adam Miartus <amiartus@de.adit-jv.com>
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>
This change adapt the fix commit 6b058fda9d
("pcm: dmix: Add option to allow alignment of slave pointers")
for dshare 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 dshare 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>
In snd_pcm_dshare_sync_area() when 'slave_hw_ptr' rolls over
'slave_boundary', the wrong variable is checked ('dshare->slave_hw_ptr' vs
the local 'slave_hw_ptr'). In some cases, this results in 'slave_hw_ptr'
not rolling over correctly. 'slave_size' and 'size' are then much too
large, and the for loop blocks for several minutes copying samples.
This was likely only triggered on 32-bit systems, since the PCM boundary
is computed based on LONG_MAX and is much larger on 64-bit systems.
This same change was made to pcm_dmix in commit
6c7f60f7a9 ("Fix boundary overlap”) from
June 2005.
Signed-off-by: Brendan Shanks <brendan.shanks@teradek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Configuration to reproduce:
~~~~
pcm.share_right {
type dshare
ipc_key 73
ipc_perm 0666
slave {
pcm "hw:0,0"
}
bindings {
# the seagfault happens when we don't bind channel 0
1 1
}
}
~~~~
Execute to reproduce:
~~~~
$ aplay -D plug:share_right test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Segmentation fault
~~~~
For channels whithout binding, values are set to UINT_MAX in function
`snd_pcm_direct_parse_bindings()`:
~~~~
for (chn = 0; chn < count; chn++)
bindings[chn] = UINT_MAX; /* don't route */
~~~~
But, these values are not checked when playing, which causes the segfault.
This commit fixes the issue.
Signed-off-by: Kirill Marinushkin <kmarinushkin@birdec.tech>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If plugin dshare detects underrun, it reports this to the user
via return value -EPIPE and setting dshare state to 'xrun' which is correct.
But, if user after this wants to check the stream state, it is misleadingly
reported as 'running' instead of 'xrun'.
With this behavior aplay e.g. will not do a proper underrun handling
(restarting stream) but terminates streaming.
This is due to plugin dshare always returns state of the slave pcm,
in pcm_ops->state() which is not correct.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Mounesh Sutar <sutar.mounesh@gmail.com>
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>
On snd_pcm_drain() the slave PCM driven via plugin DSHARE is not filled with
silence. Result is endless playback of buffer content until pcm is closed.
In ALSA pcm dshare plugin, called do_silence method to fix the issue.
Signed-off-by: Anant Agrawal <Anant_Agrawal@mentor.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>
snd_pcm_dshare_status() gets the underlying status from the slave PCM.
This may contain a delay value that includes elements such as codec and
other transfer delays. Use this as the base for the returned delay
value, adjusted for any frames buffered locally (within the dshare
plugin).
Note: snd_pcm_dshare_delay() is not updated.
Signed-off-by: Alan Young <consult.awy@gmail.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>
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>
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>
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>
