[plbossart]

Somehow a 10ms buffer for the deep-buffer pipe generates write errors
on the kernel side with S24 and S32_LE.

Reducing the memory footprint seems to fix the problem.

This may hide a more fundamental problem with either scheduling or
memory allocation, but for now let's solve CI and daily tests.

BugLink: #3171
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com

[paulstelian97]

rballoc should succeed with sizes >1024 right? With S16 the buffer size is 48 * 10 * 2 = 960 bytes, with S24 and S32 the buffer size is 1920 bytes. 5ms changes it to 480, respectively 960.

[plbossart]

rballoc should succeed with sizes >1024 right? With S16 the buffer size is 48 * 10 * 2 = 960 bytes, with S24 and S32 the buffer size is 1920 bytes. 5ms changes it to 480, respectively 960.

If there was an allocation failure, we should see it. But the problem is a write IO error, with firmware reporting it cannot use/consume data after the .trigger.
Or it could be a silent allocation issue, which succeeds on paper but is not working at all.

Or it could be a scheduling issue, where a pipeline which works with large number of samples cannot be serviced if it relies on scheduling information from another. I really have zero understanding of all the scheduling changes....

[xiulipan]

LGTM, the issue is very interesting. But if the configure change can fix it let try to solve it later. I think we may need to create a new issue to track it.