All of lore.kernel.org
 help / color / mirror / Atom feed
From: GitHub pull_request - opened <github@alsa-project.org>
To: alsa-devel@alsa-project.org
Subject: pcm: mmap_emul: report own appl_ptr in status
Date: Wed, 11 Nov 2026 15:32:16 +0100 (CET)	[thread overview]
Message-ID: <18e70424dacfcd00-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <alsa-project/alsa-lib/pr/541@alsa-project.org>

alsa-project/alsa-lib pull request #541 was opened from andy-brightsign:

In mmap_emul mode the mmap_emul PCM keeps its own appl_ptr apart from the slave. A playback commit forwards it and then writes the new frames to the slave with sync_slave_write(). The commit returns the full size even when that write fails or comes up short, for example after an xrun.

The status op was snd_pcm_generic_status(), which returns the slave appl_ptr. When a plugin such as softvol sits above mmap_emul, its appl_ptr follows the mmap_emul one. After a short write the two differ and snd_pcm_plugin_status() aborts on

  pcm_plugin.c: snd_pcm_plugin_status: Assertion
  `status->appl_ptr == *pcm->appl.ptr' failed.

This happens with any hw PCM whose driver lacks mmap support when it is used through plug with softvol above it, on the first xrun followed by snd_pcm_status(). We hit it on an LG SoC whose ALSA driver only offers RW access, where mpv aborts on the first xrun.

It also reproduces without hardware, with a linear PCM over mmap_emul over an ioplug slave that offers only RW_INTERLEAVED access and fails one transfer. Whether that transfer returns -EPIPE (state XRUN) or -EIO, the next snd_pcm_status() on the linear PCM aborts.

Add a status op that reports the mmap_emul appl_ptr in emulation mode for playback. It takes the frames not yet written to the slave out of avail, and adds them to delay only while the stream is running or draining, because the kernel status reports no delay in other states. A count above the buffer size means the two appl_ptrs are out of sync, as after snd_pcm_reset() on a running stream, and is ignored. Non-emulated and capture streams are unchanged.

Tested with a host reproducer: linear → mmap_emul → an RW-only ioplug slave whose write fails. Master aborts in 3 of 5 scenarios and passes all 5 with this patch. On the affected device (a driver without mmap support, used through plug with softvol), aplay asserted in 5 of 6 runs before the patch and in 0 of 20 after.

Request URL   : https://github.com/alsa-project/alsa-lib/pull/541
Patch URL     : https://github.com/alsa-project/alsa-lib/pull/541.patch
Repository URL: https://github.com/alsa-project/alsa-lib

           reply	other threads:[~2026-11-11 14:32 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <alsa-project/alsa-lib/pr/541@alsa-project.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18e70424dacfcd00-webhooks-bot@alsa-project.org \
    --to=github@alsa-project.org \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.