-
Notifications
You must be signed in to change notification settings - Fork 349
Ipc4 : add ipc4 support in google rtc audio processing #6927
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
Conversation
2486bb0 to
71cafa3
Compare
71cafa3 to
0b17497
Compare
lgirdwood
left a comment
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.
@marcinszkudlinski pls review for IPC4
0b17497 to
f632eb9
Compare
f632eb9 to
66416e5
Compare
|
@perahgren @johnylin76 ping for review. |
|
@cujomalainey any comments ? |
|
Apologies, that Cavs memory bug has consumed my time this week, will resume reviews next week |
kv2019i
left a comment
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.
Some comments inline.
66416e5 to
0926f42
Compare
|
updated to fix buffer cache release issue in copier. 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.
this seems like generic info no? Is there not a generic struct to use here?
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.
this is a generic info for all AEC modules for SOF IPC4 version
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.
Then it kind of begs the question whether this should be in some more generic header...? Could be that we don't really have a good place for this sort of shared headers that are used by a subset of modules, but worth a check.
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.
@RanderWang ping
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.
@cujomalainey sure, I get it. I will work on it
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.
done! please check it. Thanks!
0926f42 to
c8fb5eb
Compare
kv2019i
left a comment
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 @RanderWang !
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.
Then it kind of begs the question whether this should be in some more generic header...? Could be that we don't really have a good place for this sort of shared headers that are used by a subset of modules, but worth a check.
|
@RanderWang i dont know why you want to add more work for yourself. Please use the module adapter directly when adapting to ipc4 |
I get your idea, but I plan to do it step by step. I want to make it merged with simple change first, then add more change. |
|
Can one of the admins verify this patch? |
|
SOFCI TEST |
Any chance we can get this marked as a bot? |
I think this may happen when CI loses context due to a reboot @wszypelt @greg-intel @keqiaozhang pls correct me if I'm wrong or provide some context why we see this. Thanks. |
|
@RanderWang can you also check the CI result here. Thanks |
c8fb5eb to
47be951
Compare
@lgirdwood google RTC AEC is not enabled in default build so CI failure is not caused by this PR. Chrome team will has their overlay for chrome like ipc3 and enabled AEC in their overlay file |
Yes but it should be registered as a bot so it can appear as one |
|
https://github.com/gkbldcig does not really look "alive" |
Always include the URL because it's lost after a force-push: https://sof-ci.01.org/sofpr/PR6927/build4076/devicetest/index.html |
|
@RanderWang can you check again, somethings not right is the code is not used ? |
47be951 to
5361902
Compare
@lgirdwood I am %100 confident that this patch can't result to CI failure since (1) we don't add AEC support in topology, so we can't test it (2) we don't enabled GOOGLE_RTC_AEC in config. According to Kai this config should be enabled by chrome overlay config. I also check the building log, no google files are compiled. And my patch only change google file and cmake file |
5361902 to
ace3aeb
Compare
neither do some of the accounts that I get follows from e.g. https://github.com/Woodster-cloud I still think things should be labeled what they are |
ace3aeb to
321aeb2
Compare
Add ipc4 config support and hw_params setting Signed-off-by: Rander Wang <rander.wang@intel.com>
Enable dummy AEC building support but still need to enable google AEC in overlay file for chrome. Signed-off-by: Rander Wang <rander.wang@intel.com>
321aeb2 to
3b76c12
Compare
lgirdwood
left a comment
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.
@cujomalainey good for you ?


It will use google rtc audio processing mock config