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