Re: [PATCH 2/2] ALSA: pcm: auto-fill buffer with silence when draining playback

[Takashi Iwai <tiwai@suse.de>]

On Tue, 11 Apr 2023 19:23:17 +0200,
Jaroslav Kysela wrote:
> 
> 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.

Does this difference matter so much?  I guess you're concerned about
the performance, right?  This sounds a bit too complex just for the
simple purpose...

> >> - 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).

I'm thinking whether we need to change anything in the kernel side for
this at all.  Can't it be changed rather in alsa-lib side instead?


Takashi