If a rate plugin uses a node (compound) instead of a plain string for
its "converter", and that compound is not a simple string array, then
the compound will be passed as an additional parameter to the new plugin
open() function (SND_PCM_RATE_PLUGIN_CONF_ENTRY(XXX)). The previous
open() function (SND_PCM_RATE_PLUGIN_ENTRY(XXX)) will be called if the
CONF version is not found. It is up to the plugin to determine whether
the presence of the conf parameter is mandatory.
Signed-off-by: Alan Young <consult.awy@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It should be possible to use empty mask format with extplug.
The refinement of mask via extplug is now modified,
to accept empty masks as well to work properly.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: Mounesh Sutar <sutar.mounesh@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
nanosecond part formatted with %06 will give incorrect/confusing results:
trigger_time: 154.9748287
trigger_time: 154.60109090
trigger_time: 154.110425257
time seems to run backwards...
This patch converts to us before printing
which gives the correct/expected result:
trigger_time: 154.009748
trigger_time: 154.060109
trigger_time: 154.110425
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>
This commit reverts parts of commit 4081be0b87,
because it is realy useful to use the file plugin in a capture path for
debugging. Also it fixes the truncate issue mentioned in above commit.
Additionally following MMAP access issue is considered:
$ arecord -D teeraw -M -d5 arecord.wav
Recording WAVE 'arecord.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
ALSA lib pcm/pcm_file.c:358:(snd_pcm_file_write_bytes)
write failed: Bad file descriptor
ALSA lib pcm/pcm_file.c:358:(snd_pcm_file_write_bytes)
write failed: Bad file descriptor
arecord: pcm/pcm_file.c:397: snd_pcm_file_add_frames:
Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.
Aborted by signal Aborted...
Signed-off-by: Timo Wischer <twischer@de.adit-jv.com>
Signed-off-by: Mounesh Sutar <sutar.mounesh@gmail.com>
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>
When PCM is operated in async mode and an async handler calls some PCM
functions with lock during other PCM operations, we may hit a
deadlock.
Although async mode is rarely used, it's still a possible use case.
Disable the locking when the stream is opened in async mode or it's
set to async mode via snd_pcm_async().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_pcm_nonblock() is called as snd_pcm_abort(). Since
snd_pcm_abort() is called often from a signal handler to clean things
up (e.g. aplay does it), we may face a deadlock if the signal is
raised during the locked operation.
There can be some way to check the deadlock state, but they would cost
much. Since the race condition of snd_pcm_nonblock() is quite small,
let's just drop the locking inside snd_pcm_nonblock() as a
workaround.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
slave_map[] in snd_pcm_multi_open() is a fixed size array and
obviously we have no overflow check, and eventually the program gets
an error when more than 64 channels are used.
Although we can modify the code to allocate the array dynamically, it
turned out that we can drop the whole slave_map[] thingy in this
function when looking at the code closely. In the past, it was used
to identify the one-to-many mapping. But the check was dropped, and
now it's nothing more than a sanity check.
Reported-by: Jörg Müller <joerg.mueller7744@gmail.com>
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>
mmapped capture access on some plugins can fetch data from
slave in the 'background'. A subsequent snd_pcm_wait waits
for too long time to reach avail_min threshold again.
Waiting too long leads to xruns on other devices waiting for
the capture data.
As a fix the avail_min on slave is recalculated dynamically.
V2: updated patch to fix within 80 characters per line
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For long time test case, the slave_hw_ptr will exceed the boundary
and wraparound the slave_hw_ptr. This slave boundary wraparound will
cause the rate->hw_ptr to wraparound irrespective of the
rate->boundary availability and due to that the available size goes
wrong.
Hence, to get the correct available size,
- Its necessary to increment the rate->hw_ptr upto the rate->boundary
and then wraparound the rate->hw_ptr.
- While handling fraction part of slave period, rounded value will be
introduced by input_frames(). To eliminate rounding issue on
rate->hw_ptr, subtract last rounded value from rate->hw_ptr and add
new rounded value of present slave_hw_ptr fraction part to
rate->hw_ptr.
Signed-off-by: mahendran.k <mahendran.kuppusamy@in.bosch.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>
Plugin file provides no private hw_ptr and appl_ptr but instead links
them to the slave pcm. If the slave pcm itself changes its hw_ptr or
app_prt this needs to be done in file plugin, too.
Plugin 'plug' is such a candidate changing the hw_ptr and app_ptr in
hw_params call dependent on the automatically inserted plugins. ALSA
unfortunately has no support for automatically updating chained
pointers.
A notification on pointer change seems to be prepared inside the
snd_pcm_set_ptr() routine via rbptr->changed(), but it is not (yet)
implemented so that we need to care for it manually.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_pcm_rate_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 rate
plugin).
Also update snd_pcm_rate_delay() similarly.
[fixed some comments by tiwai]
Signed-off-by: Alan Young <consult.awy@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a design of ALSA PCM interface, for PCM frame transmission to/from
kernel space, applications can select from two options; direct memory access
or ioctl(2). Available options are decided depending on device capacity and
machine architecture. Applications can get available options by the first
entry of 'struct snd_pcm_hw_params.masks'.
When the mask includes 'SNDRV_PCM_ACCESS_MMAP_xxx', applications can use
direct memory access. For this use case, userspace library has two types
of PCM API. One is to expose a pointer over the memory to start
reading/writing PCM frames. Another is to copy PCM frames between the
memory and a given buffer.
Current documentation includes wrong references to these APIs to describe
their advantages/disadvantages. This confuses application developers
because the references indicate PCM APIs to execute ioctl(2) operation to
read/write PCM frames.
This commit fixes the bug.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
I noticed that some plugin codes have no proper PCM state checks and
it results in expected outcomes. For example, when snd_pcm_drain() is
called for a dmix PCM after calling snd_pcm_drop(), it stalls
unexpectedly. It's just because its drain callback doesn't expect the
SND_PCM_SETUP state.
We can fix such a bug in each place one by one, but a safer way would
be to filter out all such cases commonly in the PCM API functions
themselves. This patch adds the PCM state sanity checks to major API
functions so that they return -EBADFD when called in the unexpected
PCM states.
As well as for the thread-safety extension, it'd be a question of the
performance; again at this time, the hw PCM is considered as an
exception, and it has pcm->own_state_check flag set, which means that
the common PCM state checks are skipped.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit f8d07a7354.
The htimestamp field was already intiailized. It was just overlooked,
sorry.
Suggested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
PCM operation htimestamp is not implemented in plugin file.
Calling snd_pcm_htimestamp() on a plugin file crashes. This scenario
is considered now.
Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
Signed-off-by: Joshua Frkuska <joshua_frkuska@mentor.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>
Otherwise, they will linger after the error is returned (but pcm->setup == 0).
Then, if the caller tries to clean up and call snd_pcm_close(), the assertion
plug->gen.slave == plug->req_slave will fail.
Signed-off-by: Michael Forney <mforney@mforney.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The newly added locking code seems to have confused quite a few
people, as "thread_safe=1" may be considered as if the thread-safety
lock has to be turned on. (It meant that the plugin _is_ thread-safe,
i.e. it needs no extra locking.)
For avoiding such a misunderstanding, this commit renames the relevant
pcm fields and give more comments to explain what is for what.
The former single pcm->thread_safe flag is now split to two boolean
flags, pcm->need_lock and pcm->lock_enabled. It consumes a few more
bytes, but this would be (hopefully) better understandable.
No functional change by this commit.
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>
In this development period, some APIs have already been added. Most of
them are to add an element set, while their names are not so appropriate
against their feature. This is due to following to names of old APIs.
This commit renames them.
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_softvol_open().
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 softvol_load_control().
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>
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>
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>
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>
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>
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_hw_change_timer().
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>
