From: Takashi Iwai <tiwai@suse.de>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [PATCH 2/2] ALSA: pcm: auto-fill buffer with silence when draining playback
Date: Thu, 13 Apr 2023 14:06:49 +0200 [thread overview]
Message-ID: <87edoovvdy.wl-tiwai@suse.de> (raw)
In-Reply-To: <ZDfjKgLJ2tpV45eW@ugly>
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
next prev parent reply other threads:[~2023-04-13 12:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 20:12 [PATCH 1/2] ALSA: pcm: rewrite snd_pcm_playback_silence() Oswald Buddenhagen
2023-04-05 20:12 ` [PATCH 2/2] ALSA: pcm: auto-fill buffer with silence when draining playback Oswald Buddenhagen
2023-04-07 23:58 ` Jaroslav Kysela
2023-04-08 5:55 ` Takashi Iwai
2023-04-08 7:24 ` Oswald Buddenhagen
2023-04-11 11:09 ` Jaroslav Kysela
2023-04-11 13:57 ` Oswald Buddenhagen
2023-04-11 14:48 ` Jaroslav Kysela
2023-04-11 16:50 ` Oswald Buddenhagen
2023-04-11 17:23 ` Jaroslav Kysela
2023-04-12 7:54 ` Takashi Iwai
2023-04-12 8:04 ` Oswald Buddenhagen
2023-04-12 10:37 ` Takashi Iwai
2023-04-12 11:38 ` Oswald Buddenhagen
2023-04-12 19:59 ` Jaroslav Kysela
2023-04-13 5:42 ` Takashi Iwai
2023-04-13 10:16 ` Oswald Buddenhagen
2023-04-13 10:28 ` Takashi Iwai
2023-04-13 11:10 ` Oswald Buddenhagen
2023-04-13 12:06 ` Takashi Iwai [this message]
2023-04-13 14:59 ` Oswald Buddenhagen
2023-04-14 8:26 ` Takashi Iwai
2023-04-14 8:56 ` Oswald Buddenhagen
2023-04-14 9:28 ` Takashi Iwai
2023-04-06 14:53 ` [PATCH 1/2] ALSA: pcm: rewrite snd_pcm_playback_silence() Takashi Iwai
2023-04-11 10:47 ` Jaroslav Kysela
2023-04-12 10:33 ` Oswald Buddenhagen
2023-04-12 19:23 ` Jaroslav Kysela
2023-04-13 9:44 ` Oswald Buddenhagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edoovvdy.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=oswald.buddenhagen@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.