[BUG] alsa_conformance_test fails with 11.025Hz on PTL nocodec and new FW

[kv2019i]

Describe the bug
Regression in SOF git commit a32d983

To Reproduce
alsa_conformance_test -P hw:sofnocodec,2 -d 0.1 -r 11025 -B 55 -c 2 -f S16_LE -p 55 --avail-delay

Reproduction Rate
100%

Expected behavior
Test passes

Impact
Unable to use SRC as configured in PTL nocodec topology

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: latest sof-dev
   • SOF: latest sof-main
2. Name of the topology file
   • Topology: sof-ptl-nocodec.tplg
3. Name of the platform(s) on which the bug is observed.
   • Platform: Intel ptl

Screenshots or console output

[ 1966.940790] <inf> src_set_params: comp:0 0x100f SRC DP period calculated as: 1000 us
[ 1966.940811] <inf> src_params_general: comp:0 0x100f source_rate = 11025, sink_rate = 48000
[ 1966.940833] <err> module_adapter: z_impl_mod_alloc_ext: comp:0 0x100f Failed to alloc 14512 bytes 0 alignment for comp 0x100f.                                                                                                                             [ 1966.940843] <err> src_params_general: comp:0 0x100f failed to alloc cd->delay_lines, delay_lines_size = 14512
[ 1966.940868] <err> module_adapter: module_prepare: comp:0 0x100f error -22: module specific prepare failed
[ 1966.940873] <err> module_adapter: module_adapter_prepare: comp:0 0x100f error -22: module prepare failed

[kv2019i]

FYI @jsarha . Seems 20*1024 is the minimum to pass this test:

        const size_t buf_size = 20 * 1024; /* works (before change) */
        const size_t buf_size = 19 * 1024; /* fails */
        const size_t buf_size = 16 * 1024; /* fails (current main) */

What test was failing originally? #10587 does refer to any test case or scenario.

[jsarha]

I am afraid it was not any of our regular tests but one of the manual test I've been using. There I start capture and playback on hw:0,2 at the same time, so that there is two DP SRC modules. There is apparently not enough over 20k blocks available for the two of them in the rballoc configuration. So as a an easy remedy we can at least try if CI passes successfully with a32d983 reverted.

[kv2019i]

Ok thanks @jsarha . We have multiple changes on the way to make ths configuration more flexible, so I think your #10689 is a good meausre for now. Passing this to you for 10689 integration.