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

[Keyon Jie]

On 2020/1/19 下午6:43, Takashi Iwai wrote:
> On Sun, 19 Jan 2020 11:14:56 +0100,
> Keyon Jie wrote:
>>
>> On 2020/1/19 下午5:04, Takashi Iwai wrote:
>>> On Sun, 19 Jan 2020 09:11:17 +0100,
>>> Keyon Jie wrote:
>>>> On 2020/1/19 下午3:09, Takashi Iwai wrote:
>>>> It varies for each stream, most of them are 65536 Bytes only, whereas
>>>> one for Wake-On-Voice might need a > 4 Seconds buffer could be up to
>>>> about 1~2MBytes, and another one for deep-buffer playback can be up to
>>>> about 8MBytes.
>>> Hm, so this varies so much depending on the use case?
>>> I thought it comes from the topology file and it's essentially
>>> consistent over various purposes.
>>
>> Yes, we add different buffer_bytes_max limitation to each stream
>> depending on its use case, basically we set it to the maximum value we
>> claim to support only, we don't want to waste any of the system
>> memory.
>>
>>>
>>>>> 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
>>>> Just did an experiment and this works for me, I believe we still need
>>>> to call snd_pcm_set_managed_buffer() though the preallocation is
>>>> skipped in this, right?
>>> No, snd_pcm_set_managed_buffer() is the new PCM preallocation API.
>>> The old snd_pcm_lib_preallocate*() is almost gone.
>>
>> What I asked is actually that since the preallocation will be
>> skipped(with passing size=0), can we just not calling
>> snd_pcm_set_managed_buffer() or snd_pcm_lib_preallocate*() in our SOF
>> PCM driver? I believe no(we still need the invoking to do
>> initialization except buffer allocating)?
> 
> You still need to call it.  Otherwise the PCM core doesn't know what
> kind of buffer type has to be allocated.
> 
> Basically snd_pcm_set_managed_buffer() or snd_pcm_lib_preallocate*()
> does two things: set the buffer type and its preallocation (default
> and max size).  The latter default size can be 0, meaning that no
> default preallocation is performed.  Also the max can be 0, i.e. no
> preallocation is needed at all for the buffers (e.g. vmalloc
> buffers).  Meanwhile the buffer type and its device pointer are
> mandatory and can't be skipped.

Got it, thanks for guiding on it Takashi.

Thanks,
~Keyon

> 
>>>
>>>>> 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.
>>>> OK, that's fine for me also, thank you.
>>> Below is a quick hack for HDA.  We still need the certain amount of
>>> preallocation for non-x86 systems that don't support SG-buffers, so
>>> a bit of trick is applied to Kconfig.
>>>
>>> Totally untested, as usual.
>>
>> Did a quick test(plus passing 0 size for preallocate in SOF PCM
>> driver) and it works for my use case(no regression comparing that
>> without applying this patch), Thank you.
> 
> OK, will tidy up and submit later.
> 
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>