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

[Keyon Jie <yang.jie@linux.intel.com>]

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@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel