On Thu, 13 Apr 2023 13:10:34 +0200, Oswald Buddenhagen wrote: > > On Thu, Apr 13, 2023 at 12:28:34PM +0200, Takashi Iwai wrote: > > On Thu, 13 Apr 2023 12:16:04 +0200, Oswald Buddenhagen wrote: > >> On Thu, Apr 13, 2023 at 07:42:06AM +0200, Takashi Iwai wrote: > >> > Also, we may skip the > >> > workaround for applications accessing directly via mmap as default. > >> > no, because one may easily miss that more than one period is > >> required. > >> also, i think that forgetting it entirely is an easy mistake to make, > >> even if it's harder with mmap than with write. > > > > I don't agree with that point -- if application wants the access only > > via mmap (without any write actions via alsa-lib functions), the > > buffer and data management relies fully on the application itself. > > Manipulating the data *silently* is no good action for such > > applications. > > > For them, the drain simply means to stop at the certain point. > > > i don't think that's true. if an app wants to control things finely, > it would just use start/stop and manage the timing itself. draining > otoh is a convenient fire-and-forget operation. that makes it easy to > miss the finer details, which is why i'm so insistent that it should > just work out of the box. Sure, but that's still no excuse to ignore the possibility blindly. > if you exclude mmapped devices in kernel, you exclude plughw with > emulated write(), so you'd have to add yet more code to compensate for > that. No, I wrote "if application wants the access only via mmap (without any write actions via alsa-lib functions)". So if application writes via plugin write(), we should apply the workaround, too. > and doing it all in user space is yet more code. for all i can > tell, it's really just layers of complexity to solve a non-problem. I don't get it: we're talking about the sw_params call in alsa-lib's drain function, and how can it be *so* complex...? Takashi
