alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Keyon Jie <yang.jie@linux.intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"Rajwa, Marcin" <marcin.rajwa@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue
Date: Sun, 19 Jan 2020 08:09:15 +0100	[thread overview]
Message-ID: <s5himl7orc4.wl-tiwai@suse.de> (raw)
In-Reply-To: <7c6bb315-1ffc-665d-ff5e-e5e440f3e609@linux.intel.com>

On Sun, 19 Jan 2020 04:52:55 +0100,
Keyon Jie wrote:
> 
> 
> On 2020/1/17 下午7:12, Takashi Iwai wrote:
> > On Fri, 17 Jan 2020 11:43:24 +0100,
> > Keyon Jie wrote:
> >>
> >> In SOF driver, we don't use kernel config item like
> >> CONFIG_SND_HDA_PREALLOC_SIZE for HDA, the code for it is:
> >>
> >> 	snd_pcm_lib_preallocate_pages(pcm->streams[stream].substream,
> >> 				      SNDRV_DMA_TYPE_DEV_SG, sdev->dev,
> >> 				le32_to_cpu(caps->buffer_size_min),
> >> 				le32_to_cpu(caps->buffer_size_max));
> >>
> >> So the preallocated size is configured via topology file, that is
> >> caps->buffer_size_min, no chance for PulseAudio to reconfigure it.
> >>
> >> So, it looks like we have to change it to this if we don't change the
> >> ALSA core:
> >>
> >> 	snd_pcm_lib_preallocate_pages(pcm->streams[stream].substream,
> >> 				      SNDRV_DMA_TYPE_DEV_SG, sdev->dev,
> >> -				le32_to_cpu(caps->buffer_size_min),
> >> +				le32_to_cpu(caps->buffer_size_max),
> >> 				le32_to_cpu(caps->buffer_size_max));
> >
> > Yes, passing buffer_size_min for the preallocation sounds already
> > bad.  The default value should be sufficient for usual operations, not
> > the cost-cutting minimum.  Otherwise there is no merit of
> > preallocation.
> >
> > Alternatively, we may pass 0 there, indicating no limitation, too.
> > But, this would need a bit other adjustment, e.g. snd_pcm_hardware
> > should have lower buffer_bytes_max.
> 
> Thank you Takashi, then let's follow it to pre-allocate with
> caps->buffer_size_max, as we don't specify any limitations in
> snd_pcm_hardware today, we want to leave it configurable to each
> specific topology file for different machines.

How big is caps->buffer_size_max?  Passing the value there means
actually trying to allocate the given size as default, and it'd be a
lot of waste if a too large value (e.g. 32MB) is passed there.

I think we can go for passing zero as default, which means skipping
preallocation.  In addition, we may add an upper limit of the total
amount of allocation per card, controlled in pcm_memory.c, for
example.  This logic can be applied to the legacy HDA, too.

This should be relatively easy, and I'll provide the patch in the next
week.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2020-01-19  7:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:53 [alsa-devel] [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue Keyon Jie
2020-01-16  7:15 ` Takashi Iwai
2020-01-16  9:50   ` Keyon Jie
2020-01-16 10:27     ` Takashi Iwai
2020-01-16 11:25       ` Keyon Jie
2020-01-16 11:50         ` Takashi Iwai
2020-01-16 14:14           ` Jie, Yang
2020-01-16 15:31             ` Jie, Yang
2020-01-16 16:07               ` Takashi Iwai
2020-01-16 16:39               ` Pierre-Louis Bossart
2020-01-16 17:25                 ` Rajwa, Marcin
2020-01-16 17:40                   ` Pierre-Louis Bossart
2020-01-16 20:37                     ` Takashi Iwai
2020-01-17  5:30                       ` Keyon Jie
2020-01-17  7:57                         ` Takashi Iwai
2020-01-17 10:13                           ` Keyon Jie
2020-01-17 10:30                             ` Takashi Iwai
2020-01-17 10:56                               ` Keyon Jie
2020-01-17 11:15                                 ` Takashi Iwai
2020-01-17  5:37                     ` Keyon Jie
2020-01-17  8:00                       ` Takashi Iwai
2020-01-17 10:43                         ` Keyon Jie
2020-01-17 11:12                           ` Takashi Iwai
2020-01-19  3:52                             ` Keyon Jie
2020-01-19  7:09                               ` Takashi Iwai [this message]
2020-01-19  8:11                                 ` Keyon Jie
2020-01-19  9:04                                   ` Takashi Iwai
2020-01-19 10:14                                     ` Keyon Jie
2020-01-19 10:43                                       ` Takashi Iwai
2020-01-20  2:23                                         ` Keyon Jie
2020-01-16 15:45             ` 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=s5himl7orc4.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=marcin.rajwa@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=yang.jie@linux.intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).