On 11. 04. 23 18:50, Oswald Buddenhagen wrote:
If we allow modification of the PCM buffer, I think that we should:
- Do not modify the buffer for drivers already working with the
appl_ptr data (end position) only.
i suppose that should be detected by the drain callback being set up?
Yes, but it would be probably better to add a default silencing callback with
a warning to notify authors of drivers to review and eventually correct the
behavior.
- Handle the situation with the large buffer; it may make sense
to change the "wait" operation from the end-of-period interrupt to time
scheduler and stop the drain more early when the end-of-valid data condition
is fulfilled.
i don't understand what you're asking for.
Use jiffies/timeout instead waiting to the interrupt. In this case, the stop
may be called earlier (in the middle of period). In this case the silenced
area may be much smaller.
- Increase the protocol version.
But as I wrote, I would make those extensions configurable
(SNDRV_PCM_HW_PARAMS_DRAIN_ALLOW_SILENCE). It can be turned on by default.
i have no clue what would be involved in doing that. to me that sounds
like overkill (solving a non-issue), and goes waaaay beyond what i
expected to invest into this issue (really, i just wanted to verify that
the emu10k1 fixes work, and accidentally discovered that there is a
mid-layer issue that affects user space, as the pyalsaaudio lib i'm
using doesn't handle it).
OK. I don't think that it's a pyalsaudio job to resolve the issue with the
minimal transfer chunk / period (which you set / know before the transfer is
initiated).
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
