Repository navigation
[BUG] Playback time is at half with i.MX SRC test for 11025 rate #10154
Description
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
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: linux-6.12
- SOF: main / 117e460
- Name of the topology file
- Topology: sof-imx8mp-src-wm8960.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: imx8/imx8x/imx8m
Activity
dbaluta commentedon Aug 7, 2025
@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 commentedon Aug 7, 2025
@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 commentedon Aug 8, 2025
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 commentedon Aug 12, 2025
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 commentedon Aug 12, 2025
My tplg patch to fix the issue is in #10162. Maybe a similar change would work with i.MX.
iuliana-prodan commentedon Aug 13, 2025
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 commentedon Aug 13, 2025
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 commentedon Aug 15, 2025
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 commentedon Aug 18, 2025
@singalsu will try to create a similar fix for tplg1. I wonder why the heap API change uncovered this issue though.
github-actions commentedon Oct 18, 2025
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.