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

[Keyon Jie]

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

Thanks,
~Keyon

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel