The snd_pcm_status() of the ioplug doesn't return the current
positions of hw_ptr and appl_ptr as advertised. Fix it by copying the
current values stored in the plugin data.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
The direct plugins (dmix & etc.) sets own initial
hw_ptr and appl_ptr. Use this initial settings
to export correct values in snd_pcm_status().
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The recent updates do not take in account the possible
calls for the capture stream. Fix the avail and delay
inconsistencies (and assert).
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This reverts commit aba87e5098.
The commit does not look good. The plugins must handle
the delay value correctly.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Do hw_ptr sync only once after the status call. This avoids
double update.
Also, the application pointer must not change when
the status is called. Add assert() call for this condition.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
No functional changes - move the code to snd_pcm_plugin_sync_hw_ptr()
and put the mmap capture updates to separate function for readability.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
It's no reason to sync the avail/delay fields using the mirrored
buffer pointers. The slave information must be valid.
The original report probably tries to fix something for
the specific plugin. Revert all changes.
Fixes: afe6ff3b33 ("pcm: plugin status - fix the return value (regression)")
Fixes: 4f90392f07 ("pcm: fix the snd_pcm_plugin_status() avail and delay fields")
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The snd_pcm_plugin_avail_update() error code in snd_pcm_plugin_status()
should not be reported to the caller. The state errors can be determined
using the state member in the status structure.
Fixes: 4f90392f07 ("pcm: fix the snd_pcm_plugin_status() avail and delay fields")
BugLink: https://github.com/alsa-project/alsa-lib/issues/107
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The __snd_pcm_state() must return a valid state, not an error value
when the plugin callback is not defined. Use the first state
SND_PCM_STATE_OPEN - the other functions will return the error
code depending on this state.
Link: https://lore.kernel.org/alsa-devel/20201226213547.175071-10-alexhenrie24@gmail.com/
Reported-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Set the status tstamp field so that it can be accessed with
snd_pcm_status_get_htstamp().
Signed-off-by: Jonas Holmberg <jonashg@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The syscalls may return EINTR when a signal is handled.
Implement safe_write() function which does simple write
retry.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The rewind or forward may cause the stream pointer change. Although
this patch does not fix the real meter update issue, it breaks
the possible big loops when the stream pointers are desynced with
the meters. It does not make sense to copy more samples than the
pcm buffer contains.
Link: https://lore.kernel.org/alsa-devel/f56d6a67-014a-e562-c253-830c0ec03717@ivitera.com/
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The avail and delay fields in the returned status structure does not
reflect the actual hw_ptr/appl_ptr. This change correct this.
TODO: Unfortunately, the delay might contain also information about
extra hardware / buffering delay which is hidden with this change.
Link: https://lore.kernel.org/alsa-devel/d9c1f37e-5c8d-f289-270e-c6cda7a56ce3@axis.com/
Reported-by: Jonas Holmberg <jonashg@axis.com>
Tested-by: Jonas Holmberg <jonashg@axis.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
When dmix uses non-interleaved mixing mode the offset and step width
to sum_buffer was calculated by using the dmix channels instead of
the slave channels. This leads to audio distortions due to frame
corruption.
example:
- With below configuratio, Do aplay on both device in parallel for
audio distortion
pcm.dmix_2_channels {
type dmix
ipc_key 5678293
ipc_perm 0660
ipc_gid audio
bindings [0 1]
slave {
pcm "hardware"
channels 2
periods 4
period_time 40000
}
}
pcm.dmix_1_channels {
type dmix
ipc_key 5678293
ipc_perm 0660
ipc_gid audio
bindings [0]
slave {
pcm "hardware"
channels 1
periods 4
period_time 40000
}
}
pcm.hardware {
type hw
card 0
channels 2
rate 48000
format S16_LE
}
Signed-off-by: Vijay Palaniswamy <vijay.palaniswamy@in.bosch.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This mimics snd_pcm_create_iec958_consumer in the kernel.
The rate and wordlength bits will only be modified if they are
set to "not indicated", which is now the default if no status
option is used.
This allows applications to override parameters determined from
the stream or implement channel status bits extensions without
needing to change pcm_iec958 code.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
High bitrate compressed audio data like DTS HD or MAT is usually
packed into 8-channel data. The HDMI specs state this has to be
formatted as a single IEC958 stream, compared to normal multi-
channel PCM data which has to be formatted as parallel IEC958 streams.
As this single-stream formatting mode may break existing setups that
expect non-PCM multichannel data to be formatted as parallel IEC958
streams it needs to be explicitly selected by setting the hdmi_mode
option to true.
The single-stream formatting implementation is prepared to cope with
arbitrary channel counts but only limited testing was done for channel
counts other than 8.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As Maarten Baert recently reported, the current dmix code applies the
semaphore unnecessarily around mixing streams even when the lockless
mix operation is used on x86. This was rather introduced mistakenly
at the commit 267d7c7281 ("Add support of little-endian on
i386/x86_64 dmix") where the generic dmix code was included on x86,
too.
For achieving the original performance back, this patch changes the
semaphore handling to be checked at run time instead of statically at
compile time.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
I took time to understand these functions in the context of the
rest of the code, which would have been a lot quicker with a comment
like this.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Match the equivalent funciton for playback. This is on the assumption
that values should be capped at zero, which is what _rewindable()
implements.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This looks like a simple mistake dating back to 2003 (commit 7470a5b9)
where code originated from dmix.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The previous implementation would mean that stop_threshold behaved
erratically. The intent is to detect that the buffer is too full,
and stop.
In practice, I don't think this was a bug in practice for applications
which don't adjust the stop_threshold. The line above catches those cases.
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This was the original bug that caused me to start looking at the
ring buffer functions.
In the API this is documented as:
"Delay is distance between current application frame position and
sound frame position. It's positive and less than buffer size in
normal situation, negative on playback underrun and greater than
buffer size on capture overrun. "
Because dsnoop was returning the buffer space available to the hardware
the return value was always quite large, and moved in the wrong
direction.
With this patch, dsnoop now gives results which are comparable to using
the "hw" device directly. My test case was with snd-echo3g (Layla3G).
Signed-off-by: Mark Hills <mark@xwax.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The extplug sets incorrectly the timestamping type to
gettimeofday. Copy the timestamp type from the slave pcm
as other plugins do.
The problem is visible when the
"pcm: dmix: fix sw_params handling of timestamp types in direct plugins"
patch was applied for the direct plugins.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1847508
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
x32 is the x86_64 ABI that uses 32-bit pointers, so requires loading
addresses into edi/esi/ebx rather than rdi/rsi/rbx.
Note that instructions such as movl %eax, (%rdi) do not require
updating, as loading an address into %edi zeroes the high bits, causing
the full %rdi register to hold a valid address.
Signed-off-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
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>
The pthread_mutexattr_t object should be destroyed by calling
pthread_mutexattr_destroy(), otherwise it may cause a potential
memory leak due to the different implement of pthread_mutexattr_init()
Signed-off-by: chunxu.li <chunxuxiao@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This error code can be used e.g. with echo reference PCM devices
(the SND_USE_CASE_MOD_ECHO_REF UCM token).
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
In commit b906db19ef, the snd_dlopen()
implements the automatic lookup to the ALSA_PLUGIN_DIR directory.
It is not necessary to add the absolute paths in callers now.
The plugin names are also searched in ld.so.conf paths as the fallback now,
but it should not be a big problem.
BugLink: https://github.com/alsa-project/alsa-lib/issues/34
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
once draining is done, the pcm enters the SETUP state, which ought to
be valid for snd_pcm_drain()
signed-off-by: Sylvain BERTRAND <sylvain.bertrand@legeek.net>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The recent gcc warning indicates the uninitialized variable commit_err:
pcm_rate.c:1104:6: warning: ‘commit_err’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (commit_err < 0)
^
Add a proper initialization to commit_err.
Fixes: 29041c5220 ("fix infinite draining of the rate plugin in SND_PCM_NONBLOCK mode")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
