-
Notifications
You must be signed in to change notification settings - Fork 62
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
Ipc4 : add google rtc AEC module support #125
Conversation
FW PR: thesofproject/sof#6927 |
this is about the Google RTC AEC, what;s the link with the Windows reference you made above @RanderWang ? |
Thanks, I got it. I may misunderstand that google AEC is sof AEC. I will add entry for google AEC |
0ed6676
to
7bdf996
Compare
@johnylin76 @cujomalainey pls review |
0406efa
to
049b209
Compare
rebase to latest code |
@plbossart update good for you ? |
@RanderWang conflict. |
Thanks, updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops forgot to publish these on the previous version
config/mtl.toml
Outdated
[[module.entry]] | ||
name = "RTC_AEC" | ||
uuid = "B780A0A6-269F-466F-B477-23DFA05AF758" | ||
affinity_mask = "0x3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious why this is not 0xF?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a duplication of general AEC. Let's use 0xF for RTC AEC
config/mtl.toml
Outdated
name = "RTC_AEC" | ||
uuid = "B780A0A6-269F-466F-B477-23DFA05AF758" | ||
affinity_mask = "0x3" | ||
instance_count = "1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why 1? What if we want to have one on HS and DMIC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let's use 2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mwasko could you clarify here, if the ext manifest says only 1 module instance but topology says 2 what should happen ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mwasko could you clarify here, if the ext manifest says only 1 module instance but topology says 2 what should happen ?
In such case FW should report an error on attempt to create second module instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, wont this mean generating differnt baseFWs for different topologies ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mwasko @lgirdwood can I ask a somewhat unrelated question related to the affinity_mask? Is there a good reason why some modules are restricted to core0, some to core0/1, and most do not have any restrictions.
I am specifically concerned about the core0 restriction, which I view as incompatible with the direction to allow low-latency pipelines to run on all cores. if a mixin is always on core0, then something's not adding up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@plbossart agreed, this seems to put component level restrictions on topology configuration without context. I would expect more restrictions like "MIPS estimates cannot violate this amount per core in worst case scenarios" and the stack check for this platform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mwasko @lgirdwood can I ask a somewhat unrelated question related to the affinity_mask? Is there a good reason why some modules are restricted to core0, some to core0/1, and most do not have any restrictions.
This field is used by Windows driver that has more flexible approach on how pipelines and modules are instantiated. The pipeline/component is assigned to specific core based on current CPU resource availability (MCPS).
I am specifically concerned about the core0 restriction, which I view as incompatible with the direction to allow low-latency pipelines to run on all cores. if a mixin is always on core0, then something's not adding up.
Originally Windows was grouping LL modules on Core 0 and I believe that is why Rander defined it like that. However, @plbossart is right here and with SOF we allow low-latency pipelines to run on all cores so all the built-in modules should not have affinity restrictions. The 3rd party modules affinity is up to integrator but the default option should be 'no restrictions'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @mwasko, your explanations match the little understanding I have of the modules.
@RanderWang can we have a follow-up patch to clean-up the affinity definitions for built-in modules, i.e. remove the restriction to core0 and core0-1 for all built-in modules? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I will follow up it.
Signed-off-by: Rander Wang <[email protected]>
Signed-off-by: Rander Wang <[email protected]>
@cujomalainey sorry, update late. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this spec is impossible to read at face value without the docs with you. Would be great to make the parser smarter to handle enums
No description provided.