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