Re: [PATCH] ALSA: pcm: fix buffer_bytes max constrained by preallocated bytes issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2020/1/17 下午7:12, Takashi Iwai wrote:
On Fri, 17 Jan 2020 11:43:24 +0100,
Keyon Jie wrote:



On 2020/1/17 下午4:00, Takashi Iwai wrote:
On Fri, 17 Jan 2020 06:37:16 +0100,
Keyon Jie wrote:

On 2020/1/17 上午1:40, Pierre-Louis Bossart wrote:

So, do you suggest not doing preallocation(or calling it with 0
size) for all
driver with TYPE_SG? I am fine if this is the recommended
method, I can try
this on SOF I2S platform to see if it can work as we required
for very large
buffer size.

Keyon, for the rest of us to follow this patch, would you mind
clarifying what drives the need for a 'very large buffer size',
and what order of magnitude this very large size would be.

FWIW, we've measured consistently on different Windows/Linux
platforms, maybe 10 years ago, that once you reach a buffer of 1s
(384 kB) the benefits from increasing that buffer size further are
marginal in terms of power consumption, and generate all kinds of
issues with volume updates and deferred routing changes.

We need bigger buffer on host side to compensate the wake up time
from d0ix to d0 which takes ~2 seconds on my setup. So, wiith
smaller buffer sizes like < 2 seconds we overwrite data since FW
keeps copping while host doesn't read until its up and running
again.

Right, that's a valid case, but that's 256 kB, not 'very large' or
likely to ever trigger an OOM case.

For S24_LE, it is 512KB, the point is that if we can't re-allocate
buffer at hw_params() stage, then we need follow a BKM that we have to
preallocate the largest DMA buffer that we claim to support at
pcm_new(), I think this is actually another kind of wast with these
largest pinned buffer that can't be swapped out...

Well, that's the case you'd need a larger preallocation.
I guess many distros already set it to a higher value for PulseAudio.
The default 64kB is just from historical and compatibility reason, and
we may extend it to 1MB or so now.

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.

Thanks,
~Keyon



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

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




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux