-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] [MTL] set pipeline state returned error when running RTC AEC on secondary core #8024
Comments
Cherry-picked #8000 to get new mtrace for more insight: The issue is not reproducible if google-rtc-aec.18.1 being removed from the connection: |
We have observed various IPC timeout with multi-core even with normal playback, especially if we disable mtrace output. |
The error is slightly different than #7774 though, in this case:
|
This is one kinds of IPC timed out tracked by #7774 with multi-core , seems to be a duplicate . |
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. |
Please verify if this will work with IMR context restore disabled (or just before first suspend) |
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 @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? |
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, |
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. |
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. |
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 . |
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
It failed at step 3 for IPC time out:
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
[TEST]: topology2: cavs-rt5682: enable AEC on secondary core #8050
mtrace-core1.txt
dmesg-mock-aec-core1.txt
The text was updated successfully, but these errors were encountered: