On Wed, 12 Apr 2023 21:59:28 +0200, Jaroslav Kysela wrote: > > On 12. 04. 23 12:37, Takashi Iwai wrote: > > On Wed, 12 Apr 2023 10:04:31 +0200, > > Oswald Buddenhagen wrote: > >> > >> On Wed, Apr 12, 2023 at 09:54:54AM +0200, Takashi Iwai wrote: > >>> 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? > >>> > >> it could, but it would be a lot uglier. user space would have to do a > >> "man-in-the-middle attack" on the data, while in the kernel we can > >> just slightly modify the consumer. this would be particularly obvious > >> in the case of write() access. > > > > But basically it'd be like fiddling sw_params temporarily for > > draining, I suppose? And the "attack" here can be taken too > > seriously; the whole PCM operation can be somehow interfered if a > > process may have the access to the PCM device, and changing sw_params > > itself must not introduce too much trouble. > > This looks like a sane proposal, but some drivers does not require the > silencing at all, so we can probably skip this step for them (new > SNDRV_PCM_INFO_PERFECT_DRAIN flag?). Sure, we should apply it only conditionally. Also, we may skip the workaround for applications accessing directly via mmap as default. Also we may provide a flag in asoundrc config, if any, too. The implementation in alsa-lib is more flexible in this regard. > The other not-yet-discussed option is to just print an warning in > alsa-lib that the residue samples may be played (when no silencing / > period size align is used). Then introduce a new helper function to > setup silencing for the drivers without new > SNDRV_PCM_INFO_PERFECT_DRAIN flag set. Hm, I don't think this would be useful. Spewing warnings are rather annoying or confusing for end users, and I bet the old applications wouldn't be fixed even with such annoyance. thanks, Takashi
