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