snd_pcm_avail_delay() is expected to report avail and delay values
in atomic fashion. However the function does two separate syscalls
and it cannot guarantee the avail value is the same as was used
to calculate the delay. This is a problem as the reported delay is
always relative to avail frames value.
If application (like e.g. alsa_conformance_test) uses snd_pcm_avail_delay()
to estimate the effective play position, it can observe bogus delay
values (and effective play position going backwards) if
snd_pcm_avail_delay() is called during a DMA burst where hw_ptr
moves quickly.
This commit adds a loop similar to that used in snd_pcm_hw_htimestamp()
to wait until we get a stable avail reading, and only then extract
the delay. This will avoid bogus values if function is called during
DMA bursts.
Closes: https://github.com/alsa-project/alsa-lib/pull/469
Closes: https://github.com/alsa-project/alsa-lib/issues/468
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This is basically redo of all changed and add appropriate conditions
to disable only ioctl calls, but preserve tstamp_type assignments.
Fixes: 15f2b276 ("pcm: hw: fix default timestamp type for O_APPPEND")
Fixes: 7e01443e ("pcm: hw: do not reset tstamp_type in SND_PCM_APPEND mode")
Link: https://github.com/alsa-project/alsa-lib/pull/450
Suggested-by: Signed-off-by: Kevin Groeneveld <kgroeneveld@lenbrook.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
When the first client of plugins such as dshare open the hw device they set
a default tstamp_type in snd_pcm_direct_initialize_slave based on
tstamp_type from the config file. But when subsequent clients open the same
plugin the snd_pcm_hw_open_fd function clobbers this default.
Closes: https://github.com/alsa-project/alsa-lib/pull/450
Signed-off-by: Kevin Groeneveld <kgroeneveld@lenbrook.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
spcm->info bits should be a copy of the slave PCM info as is.
While we clear the unsupported SND_PCM_INFO_PAUSE bit there, it should
be rather cleared only for the exposed info to apps, not spcm->info.
Fixes: 982786e9eb ("Fix bogus pause flag on dmix")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The fix for PCM dmix suspend/resume checks spcm->info bit of
SND_PCM_INFO_RESUME for applying a workaround for drivers with the
full resume support. This assumed that scpm->info is exposed from the
underlying slave PCM device.
The above is true for the first opened instance, but for the second
opened instance, it's a copy from the saved data in shmem. And, we
dropped SND_PCM_INFO_RESUME bit there to assure not to expose the full
resume capability to applications. This resulted in the
inconsistencies, and when the second instance is resumed at first, it
misses the snd_pcm_resume() call, hence the driver doesn't react
properly any longer.
For addressing it, we keep SND_PCM_INFO_RESUME bit in shmptr->s.info
bits as is, while dropping the bit exposed to apps in
snd_pcm_direct_hw_refine() and *_hw_params() callbacks.
Fixes: 6d1d620ead ("pcm: dmix: resume workaround for buggy driver")
Reported-and-tested-by: Chancel Liu <chancel.liu@nxp.com>
Closes: https://lore.kernel.org/DB9PR04MB94988752ED7C43B399E0BC00E3942@DB9PR04MB9498.eurprd04.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Try to explain more the output value and its relation between
format and sample bits defined by the format.
Link: https://github.com/larsimmisch/pyalsaaudio/pull/146
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The word "nominal" is not so correct here. Use similar
wording as we use in the kernel space (the bit-width of the format).
Link: https://github.com/larsimmisch/pyalsaaudio/pull/146
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
As Pavel noted, a possibility to automatically convert standard
linear samples to iec958 subframe format would be handy for latest
Raspberry HDMI driver.
Link: https://lore.kernel.org/alsa-devel/81b0be0a-5ab7-db91-21cb-0c59a55291e9@ivitera.com/
Suggested-by: Pavel Hofman <pavel.hofman@ivitera.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
I'm not sure this is the best way to describe the interaction, but I think
this needs to be mentioned in some form at least.
Closes: https://github.com/alsa-project/alsa-lib/pull/381
Signed-off-by: Zeno Endemann <zeno.endemann@mailbox.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This fixes functionality on specific setups with UBSan.
Closes: https://github.com/alsa-project/alsa-lib/pull/351
Signed-off-by: q66 <q66@chimera-linux.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
In some places samples and frames are used interchangeably, which may
be a little confusing, so update it to say 'frames' where it could matter.
Closes: https://github.com/alsa-project/alsa-lib/pull/375
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The start_treshold is defined as unsigned, so fix the condition
to allow using values avobe LONG_MAX.
Also, fix the documentation for the 64-bit platforms (INTMAX -> LONG_MAX).
Fixes: https://github.com/alsa-project/alsa-lib/issues/374
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
As noted in the github issue, the poll descriptors may change depending
on the stream parameters.
Fixes: cd04da2b ("pcm: clarify documentation of poll descriptor usage")
Fixes: https://github.com/alsa-project/alsa-lib/issues/372
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This is based on my understanding of the intended behavior, the
test/pcm.c example code, as well as the github pull request
discussion (#370).
There needs to be more clarifiaction regarding the exact semantics
of the value of the revents output parameter of
snd_pcm_poll_descriptors_revents, since there are events that do
not necessarily correspond to POLLIN or POLLOUT (such as period
events), but I believe this is a lot less obvious and needs
confirmation first.
Closes: https://github.com/alsa-project/alsa-lib/pull/370
Signed-off-by: Zeno Endemann <zeno.endemann@mailbox.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Update snd_pcm_subformat_t getters and setters so they no longer throw
warnings when building.
Closes: https://github.com/alsa-project/alsa-lib/pull/342
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Improve granularity of format selection for S32/U32 formats by adding
masks representing 20, 24 and 32 most significant bits.
Closes: https://github.com/alsa-project/alsa-lib/pull/342
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Allow userspace applications to select subformats easily just like in
snd_pcm_format_t case - by string conversion.
Closes: https://github.com/alsa-project/alsa-lib/pull/342
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The recent rearrangement of header inclusion order caused a regression
showing segfaults on 32bit Arm. The primary reason is the
inconsistent compile condition depending on the inclusion of config.h;
while most of other code include pcm_local.h (that implicitly includes
config.h) at first, pcm_direct.c doesn't do it, hence the access with
direct plugins crashes.
For fixing it, we need to include config.h at the beginning. But,
it's better to include pcm_local.h for all relevant code for
consistency. The patch does it, and also it adds the guard in
pcm_local.h for double inclusions.
Fixes: ad3a8b8b31 ("reshuffle included files to include config.h as first")
Link: https://github.com/alsa-project/alsa-lib/issues/352
Signed-off-by: Takashi Iwai <tiwai@suse.de>
config.h may contain defines like _FILE_OFFSET_BITS which influence
the system wide include files (off_t types, open -> open64 function
usage etc.).
Related: https://github.com/alsa-project/alsa-lib/pull/333
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Commit 2115cdb added a new call to the `SNDRV_PCM_IOCTL_SW_PARAMS`
ioctl on line 675 of src/pcm/pcm_hw.c, but passed the `sw_params`
argument by value; this should be passed by pointer.
I ran across this in the context of the direwolf software modem
for amateur radio; debugging details are in
https://groups.io/g/direwolf/message/8286
Fixes: https://github.com/alsa-project/alsa-lib/pull/330
Signed-off-by: Dan Cross <cross@gmail.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The silence size cannot exceed the silence threshold. Move the check
from the manual condition to the common code. This may happen for
small ring buffers (where the 1/10th second is too large).
Suggested-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add possibility to return -EINTR instead waiting for the event. The
applications may want to handle -EINTR condition themselves.
BugLink: https://github.com/alsa-project/alsa-lib/issues/228
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The snd_pcm_wait() function is called also internally from
the various plugins to wait for the drain with -1 and from i/o
routines in pcm.c.
Define two special negative timeout values to distinguish the
drain and i/o wait and calculate the maximal timeout according
the wait place.
Fixes: https://github.com/alsa-project/alsa-lib/issues/228
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The application may not require to touch the playback
sample stream for the drain operation at all. In this case,
the application is responsible to setup a silencing mechanism
for the playback or another graceful stop (like using the
rewind operation).
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Handle the driver informing us that it is not necessary to set up
silencing upon playback draining. This will be the case for drivers
which are guaranteed to not read any samples beyond the application
pointer.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
