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@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
