At Mon, 15 Jun 2015 19:54:05 +0100, Mark Brown wrote:
On Mon, Jun 15, 2015 at 06:42:39PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
On Thu, Jun 11, 2015 at 10:03:57PM +0530, Vinod Koul wrote:
HD-audio driver. A larger buffer (e.g. 2048) is preferredfor systems using PulseAudio. The default 64 is chosen justfor compatibility reasons.What are those compatibility reasons - why should users have to worry about this?
... if a user wants to reduce the memory foot print. 2MB buffers for each stream are significant size, supposing that it can have 16 streams.
That doesn't sound like a compatibility thing though? Compatibility makes it sound like things will break rather than we'll just use too much RAM. Is there anything else going on?
Before the parameter was introduced, the allocation was fixed to 64kB. Thus if you really want to make the driver behaving compatible as before, it should be 64kB -- not only reducing the memory footprint, it also keeps the same behavior.
Should this be a module parameter or something?
The buffers can be reallocated dynamically via procfs in general, but it's not practical and intuitive. That's why the similar option was provided for HDA legacy driver. It was the time when PA started accepted slowly. I don't know whether it makes sense for SKL ASoC driver, though -- it's up to you guys.
I'm not against having configuration, I just want it to be configuration that people can understand and it seems better to make the default be that for PulseAudio given how much of the common case it is now. Something like "make this smaller to reduce the default memory footprint" for example.
We have no consensus how much size should be given here; e.g. I myself am not so convinced by a merit of so big buffer allocation like 2MB.
Takashi