Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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