Repository navigation
[BUG] [MTL] set pipeline state returned error when running RTC AEC on secondary core #8024
Copy link
Copy link
Closed
Labels
Echo ReferenceApplies to echo referenceApplies to echo referenceIPC timeoutIPC timeout observedIPC timeout observedMTLApplies to Meteor Lake platformApplies to Meteor Lake platformP1Blocker bugs or important featuresBlocker bugs or important featuresbugSomething isn't working as expectedSomething isn't working as expectedmulticoreIssues observed when not only core#0 is used.Issues observed when not only core#0 is used.multicore-2coresIssues observed when 2 cores are used.Issues observed when 2 cores are used.
Description
Describe the bug
With exact same test environment as described in #8022, now update topology to run AEC capture on secondary core (using core 1 as an example):
To Reproduce
- Start spk playback:
aplay -Dhw:0,1 -c2 -r48000 -fS16_LE /home/LR.wav -vv
- Start spk feedback capture:
arecord -Dhw:0,29 /tmp/tmp.wav -c2 -r48000 -fs32_le -vv
- Start AEC capture:
arecord -Dhw:0,27 /tmp/mock_aec.wav -c4 -r48000 -fs32_le -vv -d20
It failed at step 3 for IPC time out:
7.445,208] <err> ipc: failed to wait schedule thread
[00:00:07.445,223] <err> ipc: ipc4: failed to send delayed reply
[00:00:07.491,650] <inf> ipc: ipc_cmd: rx : 0x13000002|0x1
[00:00:07.491,705] <err> ipc: ipc: invalid status 3 for RESET
[00:00:07.491,716] <err> ipc: failed to process msg 19 status 7
[00:00:07.491,728] <err> ipc: ipc4: FW_GEN_MSG failed with err 7
[00:00:07.521,030] <inf> ipc: ipc_cmd: rx : 0x46060004|0x70004
[00:00:07.521,546] <inf> ipc: ipc_cmd: rx : 0x12040000|0x0
[00:00:07.521,595] <err> ipc: ipc_comp_free(): comp id: 262149 state is 3 cannot be freed
[00:00:07.521,608] <err> ipc: ipc_pipeline_free(): module free () failed
[00:00:07.521,620] <err> ipc: ipc4: FW_GEN_MSG failed with err 12
Reproduction Rate
100%
Expected behavior
Step 3 should work as good as Step 1 & 2.
Impact
Same results are observed with Google AEC lib instead of CONFIG_GOOGLE_RTC_AUDIO_PROCESSING_MOCK.
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: {[https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-6.1}]
- SOF: {MTL-005.0.3 release} https://github.com/thesofproject/sof/releases/tag/releases%2Fmtl%2Fv5.0.3
- Name of the topology file
- Topology: {sof-mtl-max98357a-rt5682-ssp2-ssp0.tplg} plus
[TEST]: topology2: cavs-rt5682: enable AEC on secondary core #8050
- Topology: {sof-mtl-max98357a-rt5682-ssp2-ssp0.tplg} plus
- Name of the platform(s) on which the bug is observed.
- Platform: {MTL/Rex}
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Echo ReferenceApplies to echo referenceApplies to echo referenceIPC timeoutIPC timeout observedIPC timeout observedMTLApplies to Meteor Lake platformApplies to Meteor Lake platformP1Blocker bugs or important featuresBlocker bugs or important featuresbugSomething isn't working as expectedSomething isn't working as expectedmulticoreIssues observed when not only core#0 is used.Issues observed when not only core#0 is used.multicore-2coresIssues observed when 2 cores are used.Issues observed when 2 cores are used.

Activity
[-][BUG] [MTL] failed to run RTC AEC capture on secondary core[/-][+][BUG] [MTL] set pipeline state returned error when running RTC AEC on secondary core[/+]yongzhi1 commentedon Aug 11, 2023
Cherry-picked #8000 to get new mtrace for more insight:
mtrace-echo-core1.txt
The issue is not reproducible if google-rtc-aec.18.1 being removed from the connection:
cc @abonislawski @lgirdwood @RanderWang
RanderWang commentedon Aug 14, 2023
We have observed various IPC timeout with multi-core even with normal playback, especially if we disable mtrace output.
#7774 (comment)
yongzhi1 commentedon Aug 14, 2023
The error is slightly different than #7774 though, in this case:
yongzhi1 commentedon Aug 17, 2023
cc @serhiy-katsyuba-intel
mengdonglin commentedon Aug 21, 2023
This is one kinds of IPC timed out tracked by #7774 with multi-core , seems to be a duplicate .
yongzhi1 commentedon Aug 21, 2023
If I remove google-rtc-aec.18.1 from the pipeline, then the issue is not reproducible, otherwise it's 100%, so there seems to be a very specific reason.
abonislawski commentedon Aug 22, 2023
Please verify if this will work with IMR context restore disabled (or just before first suspend)
serhiy-katsyuba-intel commentedon Aug 22, 2023
The issue is no longer reproducible due to another issue. Now (with kernel from August 21) running arecord on AEC capture fails on driver side, driver does not even send any IPC to firmware:
In dmesg:
Maybe we have missing Input Pin 1 format description in manifest? Somethere on start in dmesg (note, Pin index #0 is present 2 times but no Pin index # 1):
Tested with firmware build from mtl-005-drop-stable branch with enabled
with this rimage manifest commit RanderWang/rimage@bbdbf09
and topology from PR build #8050.
@RanderWang , @yongzhi1 , can you check if AEC component input pin 1 description is correct (is present) in manifest? Or maybe you have any idea why recent driver is complaining for missing input pin 1 format of AEC?
yongzhi1 commentedon Aug 22, 2023
Hi, @serhiy-katsyuba-intel , the input pin 1 is defined here:
RanderWang/rimage@bbdbf09#diff-7d97bf1f90e10dc1f06355450d648d5dcd03b8010aaad7101077fe54611012d6R503
For the ACE use case, playback needs to be started first, followed by EchoRef, then "DMIC0 RTC AEC" at last, did you try in that order? thanks,
RanderWang commentedon Aug 23, 2023
Thanks! yong. the PR was thesofproject/rimage#125, but too many requirement can't be supported and it was only a example for AEC, so closed it. Now chrome team are working on it so @yongzhi1 you can submit one.
serhiy-katsyuba-intel commentedon Aug 25, 2023
The problem is caused by one of the components was created with extension.r.proc_domain == COMP_PROCESSING_DOMAIN_DP.
DP scheduling is NOT supported on mtl-005-drop-stable branch. Sadly, there is no clear error message when trying to use DP scheduling but just crash. That crash resulted in IPC timeout.
serhiy-katsyuba-intel commentedon Aug 25, 2023
The problem is in mtl.toml. domain_types = "1" is specified for RTC_AEC component. That parameter selects type of processing: 0 for LL, 1 for DP. Modifying domain_types to "0" solves the problem.
cc: @RanderWang , @abonislawski .