ASoC: SOF: ipc4-pcm: fix start offset calculation for chain DMA #5507
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Assumption that chain DMA module starts the link DMA when 1ms of data is available from host is not correct. Instead the firmware chain DMA module fills the link DMA with initial buffer of zeroes and the host and link DMAs are started at the same time. This results in a small error in delay calculation. This can become a more severe problem if host DMA has delays that exceed 1ms. This results in negative delay to be calculated and bogus values reported to applications. This can confuse some applications like alsa_conformance_test. Fix the issue by correctly calculating the firmware chain DMA preamble size and initializing the start offset to this value. Fixes: a1d203d ("ASoC: SOF: ipc4-pcm: Enable delay reporting for ChainDMA streams") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
requested review from
bardliao,
dbaluta,
lgirdwood,
plbossart,
ranj063 and
ujfalusi
as code owners
Collaborator
Author
|
Issue found while developing #5499 |
kv2019i
commented
Aug 11, 2025
| * alignment that is not known to host. | ||
| */ | ||
| time_info->stream_start_offset = substream->runtime->rate / MSEC_PER_SEC; | ||
| int pre_ms = SOF_IPC4_CHAIN_DMA_BUF_SIZE_MS * 5 / 2 + 1; |
Collaborator
Author
There was a problem hiding this comment.
FW code calculates above as '2 * 5 / 2', convert to bytes and aligns up to DMA transfer size. We could calculate this exactly, but not sure if it will add value here.
kv2019i
changed the title
Collaborator
Author
|
Let me mark with a DNM briefly. I need to double check this after a new chain-DMA issue found on FW side. Will link to the PR once it is ready. |
kv2019i
changed the title
Collaborator
Author
|
Cleared the DNM, this is valid in its current form. I double-checked the behaviour from host/link DMA status dumps during the startup sequence and it matches the patch now. |
bardliao
approved these changes
Aug 21, 2025
Collaborator
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Assumption that chain DMA module starts the link DMA when 1ms of data is available from host is not correct. Instead the firmware chain DMA module fills the link DMA with initial buffer of zeroes and the host and link DMAs are started at the same time.
This results in a small error in delay calculation. This can become a more severe problem if host DMA has delays that exceed 1ms. This results in negative delay to be calculated and bogus values reported to applications. This can confuse some applications like alsa_conformance_test.
Fix the issue by correctly calculating the firmware chain DMA preamble size and initializing the start offset to this value.
Fixes: a1d203d ("ASoC: SOF: ipc4-pcm: Enable delay reporting for ChainDMA streams")