Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

RanderWang
Copy link
Contributor

No description provided.

config/tgl-cavs.toml Outdated Show resolved Hide resolved
@RanderWang
Copy link
Contributor Author

FW PR: thesofproject/sof#6927

@plbossart
Copy link
Member

FW PR: thesofproject/sof#6927

this is about the Google RTC AEC, what;s the link with the Windows reference you made above @RanderWang ?

@RanderWang
Copy link
Contributor Author

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

@RanderWang RanderWang force-pushed the ipc4-eac branch 2 times, most recently from 0ed6676 to 7bdf996 Compare January 11, 2023 09:14
@RanderWang RanderWang changed the title Ipc4 : add AEC module support Ipc4 : add google rtc AEC module support Jan 11, 2023
@lgirdwood
Copy link
Member

@johnylin76 @cujomalainey pls review

config/mtl.toml Show resolved Hide resolved
config/tgl-cavs.toml Show resolved Hide resolved
@RanderWang
Copy link
Contributor Author

rebase to latest code

@lgirdwood
Copy link
Member

@plbossart update good for you ?

lgirdwood
lgirdwood previously approved these changes Feb 8, 2023
@lgirdwood
Copy link
Member

@RanderWang conflict.

@RanderWang
Copy link
Contributor Author

@RanderWang conflict.

Thanks, updated

lgirdwood
lgirdwood previously approved these changes Feb 20, 2023
Copy link
Member

@cujomalainey cujomalainey left a 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"
Copy link
Member

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?

Copy link
Contributor Author

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"
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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 ?

Copy link

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.

Copy link
Member

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 ?

Copy link
Member

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.

Copy link
Member

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.

Copy link

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'.

Copy link
Member

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!

Copy link
Contributor Author

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.

config/mtl.toml Show resolved Hide resolved
config/mtl.toml Outdated Show resolved Hide resolved
Signed-off-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Rander Wang <rander.wang@intel.com>
@RanderWang
Copy link
Contributor Author

@cujomalainey sorry, update late.

Copy link
Member

@cujomalainey cujomalainey left a 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

config/tgl-cavs.toml Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants