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