[BUG] Playback time is at half with i.MX SRC test for 11025 rate

[dbaluta]

Describe the bug

Running aplay -Dhw:2,0 -f S32_LE -c 2 -r 11025 sample.wav

using SRC topology we can see that the sound is faster.

Measuring time it looks like WAV playback time is half from what it should be.

It looks like the problem appeared after commit:

commit 5821682809c73dd2a49f8e1649a2e6c60ef2b092 (HEAD)
Author: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Date:   Fri Jul 4 15:57:31 2025 +0100

    heap: simplify heap API.
    
    Use a Linux kernel like heap API now that zephyr allocator deals with
    the complexity.

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: linux-6.12
   • SOF: main / 117e460
2. Name of the topology file
   • Topology: sof-imx8mp-src-wm8960.tplg
3. Name of the platform(s) on which the bug is observed.
   • Platform: imx8/imx8x/imx8m

[dbaluta]

@lgirdwood did you see any issues after this patch on Intel platforms. Looks like on NXP IMX platforms all works well except for the tests with 11025 rate.

This is quite unusual as printing the parameters and allocated addressed there is nothing that is out of ordinary. Any clue?

[lgirdwood]

@singalsu is also looking at 11025 issue on Intel. We are looking at cache/DMA alignments as working on testbench. Best for @singalsu to update.

[singalsu]

I made just PR #10158 but not sure it helps, it doesn't look like root cause but part of a workaround if it's a DMA issue. It starts source consume and sink produce in first copy(). Also I could get clean 11.025 kHz capture by adding a volume component into pipeline before host. It also makes the samples traffic more steady with it's data align constraints.

But the issue that we see in IPC4 system isn't half capture time, playback has been clean, but glitches at regular quite long tens of ms intervals.

[singalsu]

I'm now debugging a possible SRC internal issue, triggered by possibly too small sink buffer to operate. @dbaluta Is this in i.MX for 48 kHz to 11.025 kHz capture? What buffer sizes are used for SRC source and sink.

In the Intel platform for these rates the source for stereo S32_LE is 768 bytes and sink 192 bytes. Since the host-copier DMA leaves excess of 12 frames not copied it may be that sink buffer isn't large enough for next copy() processing to happen. But the component should error the operation and not continue with glitches if so. But this is my suspicion, not confirmed yet.

[singalsu]

My tplg patch to fix the issue is in #10162. Maybe a similar change would work with i.MX.

[iuliana-prodan]

I made just PR #10158 but not sure it helps, it doesn't look like root cause but part of a workaround if it's a DMA issue. It starts source consume and sink produce in first copy(). Also I could get clean 11.025 kHz capture by adding a volume component into pipeline before host. It also makes the samples traffic more steady with it's data align constraints.

But the issue that we see in IPC4 system isn't half capture time, playback has been clean, but glitches at regular quite long tens of ms intervals.

In case of i.MX the problem is on playback with source_rate = 11025 and sink_rate = 48000.
The source buffer is 192 bytes and sink is 2304 bytes, for stereo S32_LE.

[iuliana-prodan]

My tplg patch to fix the issue is in #10162. Maybe a similar change would work with i.MX.

We are still using topology1 and I'm not sure how to make a similar change for that.
Should I try to increase the source buffer size? How can I do that in tplg1?

[lgirdwood]

My tplg patch to fix the issue is in #10162. Maybe a similar change would work with i.MX.

We are still using topology1 and I'm not sure how to make a similar change for that. Should I try to increase the source buffer size? How can I do that in tplg1?

Yes, but I've not touched tplg1 in a while, but I do remember we had a macro for buffer size in the pipelines.

[dbaluta]

@singalsu will try to create a similar fix for tplg1. I wonder why the heap API change uncovered this issue though.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.