From: Takashi Iwai <tiwai@suse.de>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: alsa-devel@alsa-project.org, Jaroslav Kysela <perex@perex.cz>
Subject: Re: [PATCH 6/9] ALSA: emu10k1: fix PCM playback buffer size constraints
Date: Wed, 17 May 2023 22:25:00 +0200 [thread overview]
Message-ID: <874joa1zab.wl-tiwai@suse.de> (raw)
In-Reply-To: <20230517174256.3657060-6-oswald.buddenhagen@gmx.de>
On Wed, 17 May 2023 19:42:53 +0200,
Oswald Buddenhagen wrote:
>
> The period_bytes_min parameter made no sense at all, as it didn't
> correlate with any hardware limitation.
Does the device really work with less than 64 bytes period size?
I meant not in theory but in practice. Without any value set,
dumb applications may try to set 4 bytes for period size, so setting
some practical limit still makes sense.
Takashi
> The same can be said of the buffer_bytes minimum constraint.
> Instead, apply a buffer_size constraint, which works on frames.
>
> Sync up the constraints of the EFX playback with those of the regular
> playback, as there is no reason for them to diverge.
>
> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
> ---
> sound/pci/emu10k1/emupcm.c | 38 ++++++++++++++++++++++++++------------
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/sound/pci/emu10k1/emupcm.c b/sound/pci/emu10k1/emupcm.c
> index feb575922738..5226f0978408 100644
> --- a/sound/pci/emu10k1/emupcm.c
> +++ b/sound/pci/emu10k1/emupcm.c
> @@ -457,9 +457,8 @@ static const struct snd_pcm_hardware snd_emu10k1_efx_playback =
> .rate_max = 48000,
> .channels_min = NUM_EFX_PLAYBACK,
> .channels_max = NUM_EFX_PLAYBACK,
> - .buffer_bytes_max = (64*1024),
> - .period_bytes_min = 64,
> - .period_bytes_max = (64*1024),
> + .buffer_bytes_max = (128*1024),
> + .period_bytes_max = (128*1024),
> .periods_min = 2,
> .periods_max = 2,
> .fifo_size = 0,
> @@ -851,7 +850,6 @@ static const struct snd_pcm_hardware snd_emu10k1_playback =
> .channels_min = 1,
> .channels_max = 2,
> .buffer_bytes_max = (128*1024),
> - .period_bytes_min = 64,
> .period_bytes_max = (128*1024),
> .periods_min = 1,
> .periods_max = 1024,
> @@ -956,25 +954,46 @@ static int snd_emu10k1_efx_playback_close(struct snd_pcm_substream *substream)
> return 0;
> }
>
> +static int snd_emu10k1_playback_set_constraints(struct snd_pcm_runtime *runtime)
> +{
> + int err;
> +
> + // The buffer size must be a multiple of the period size, to avoid a
> + // mismatch between the extra voice and the regular voices.
> + err = snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> + if (err < 0)
> + return err;
> + // The hardware is typically the cache's size of 64 frames ahead.
> + // Leave enough time for actually filling up the buffer.
> + err = snd_pcm_hw_constraint_minmax(
> + runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 256, UINT_MAX);
> + return err;
> +}
> +
> static int snd_emu10k1_efx_playback_open(struct snd_pcm_substream *substream)
> {
> struct snd_emu10k1 *emu = snd_pcm_substream_chip(substream);
> struct snd_emu10k1_pcm *epcm;
> struct snd_emu10k1_pcm_mixer *mix;
> struct snd_pcm_runtime *runtime = substream->runtime;
> - int i, j;
> + int i, j, err;
>
> epcm = kzalloc(sizeof(*epcm), GFP_KERNEL);
> if (epcm == NULL)
> return -ENOMEM;
> epcm->emu = emu;
> epcm->type = PLAYBACK_EFX;
> epcm->substream = substream;
>
> runtime->private_data = epcm;
> runtime->private_free = snd_emu10k1_pcm_free_substream;
> runtime->hw = snd_emu10k1_efx_playback;
> -
> + err = snd_emu10k1_playback_set_constraints(runtime);
> + if (err < 0) {
> + kfree(epcm);
> + return err;
> + }
> +
> for (i = 0; i < NUM_EFX_PLAYBACK; i++) {
> mix = &emu->efx_pcm_mixer[i];
> for (j = 0; j < 8; j++)
> @@ -1005,12 +1024,7 @@ static int snd_emu10k1_playback_open(struct snd_pcm_substream *substream)
> runtime->private_data = epcm;
> runtime->private_free = snd_emu10k1_pcm_free_substream;
> runtime->hw = snd_emu10k1_playback;
> - err = snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
> - if (err < 0) {
> - kfree(epcm);
> - return err;
> - }
> - err = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 256, UINT_MAX);
> + err = snd_emu10k1_playback_set_constraints(runtime);
> if (err < 0) {
> kfree(epcm);
> return err;
> --
> 2.40.0.152.g15d061e6df
>
next prev parent reply other threads:[~2023-05-17 20:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 17:42 [PATCH 1/9] ALSA: emu10k1: pass frame instead of byte addresses Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 2/9] Revert "ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)" Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 3/9] ALSA: emu10k1: remove pointless displacement of the extra voices Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 4/9] ALSA: emu10k1: skip pointless cache setup for " Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 5/9] ALSA: emu10k1: fix PCM playback cache and interrupt handling Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 6/9] ALSA: emu10k1: fix PCM playback buffer size constraints Oswald Buddenhagen
2023-05-17 20:25 ` Takashi Iwai [this message]
2023-05-18 7:57 ` Oswald Buddenhagen
2023-05-18 8:17 ` Takashi Iwai
2023-05-17 17:42 ` [PATCH 7/9] ALSA: emu10k1: improve API of low-level voice manipulation functions Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 8/9] ALSA: emu10k1: refactor PCM playback cache filling Oswald Buddenhagen
2023-05-17 17:42 ` [PATCH 9/9] ALSA: emu10k1: refactor PCM playback address handling Oswald Buddenhagen
2023-05-18 5:32 ` [PATCH 1/9] ALSA: emu10k1: pass frame instead of byte addresses Takashi Iwai
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=874joa1zab.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=oswald.buddenhagen@gmx.de \
--cc=perex@perex.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox