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

Audio: Fix the kconfig error of mixin_mixout. #8791

Merged
merged 1 commit into from
Feb 23, 2024

Conversation

andrula-song
Copy link
Contributor

The original content of mixin_mixout kconfig is incorrect, that is for aria. This commit fix that error.

@andrula-song andrula-song marked this pull request as ready for review January 29, 2024 02:11
Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aria change looks good, but I wonder if COMP_MIXER just causes more room for confusion. @marc-hb please check

Applied gain is in range <1, 2 power attenuation>
Currently ARIA introduces gain transition and algorithmic
latency equal to 1 ms.
config COMP_MIXER
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, it doesn't seem correct to have two COMP_MIXER definitions with different semantics. This works now as Zephyr and XTOS builds use different Kconfigs (and this is getting slowly fixed in #8606 ), but this seems very confusing. Maybe better to just fix the extra ARIA defintiion and leave COMP_MIXER intact.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually there shouldn't be any info about ARIA here, it is just an error we didn't realize before. I also don't think it would be a good choice to use 2 COMP_MIXER definitions, but don't know which solution is better.

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, add a Fixes commit abcdef ("...") line in the commit message so we know for how long this didn't work.

I also don't think it would be a good choice to use 2 COMP_MIXER definitions,

Why do we need two different directories?

  • Either the IPC3 "mixer" and the IPC4 "mixin_mixout" are significantly different features that need a different name. Then don't add a new IPC4 COMP_MIXER. Instead a new, IPC4 COMP_MIXIN_MIXOUT option. Keep the single IPC3 COMP_MIXER.

  • Or, the IPC3 "mixer" and the IPC4 "mixin_mixout" are the same feature. Then merge the two directories with a git mv mixin_mixout/* mixer/. Single COMP_MIXER for both in the same directory. You can preserve the filenames, they're not part of the Kconfig user interface.

but don't know which solution is better.

I don't have any opinion as long as the Kconfig names are consistent with the directory names.

How was this done for other components?

@marc-hb
Copy link
Collaborator

marc-hb commented Jan 29, 2024

The original content of mixin_mixout kconfig is incorrect, that is for aria.

BTW it's not obvious what "that" is in this sentence. I suspect this contributed to Kai's confusion.

This commit fix that error.

Please use a basic grammar checker, it helps too. There seems to be one embedded in everything nowadays.

So I think you meant this:

Due to a copy/paste error in commit abcdedf ("..."), the content of mixin_mixout/Kconfig has been a copy of aria/Kconfig for the last 2 months.
...

The mixer seems like a pretty important component. So what have been the effects of this error for the last 2 months? The consequences (big or small) must be described briefly in the commit message. Or even described in a Github issue if the problem is too complex for a commit message (hopefully not needed this time).

@andrula-song andrula-song marked this pull request as draft January 30, 2024 02:28
Fixes the commit f4d0437 ("Audio: Move components related config
to subfolder").

Due to a copy/paste error, the content of mixin_mixout/Kconfig has
been a copy of aria/Kconfig. This patch fixes the copy/paste error,
and adds IPC version dependence for COMP_MIXER and COMP_MIXIN_MIXOUT.

Signed-off-by: Andrula Song <[email protected]>
@andrula-song
Copy link
Contributor Author

hi, @kv2019i @marc-hb , can you help to review?

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I missed your force-pushed. Also, you didn't update the description which didn't help.

So aceef1a was initially was a minor Kconfig fix without a bug description.

Now there is a commit message in 9633be7 that described the Kconfig change well but:

  1. Still no explanation of how this was broken for 2 months without anyone noticing. Is anyone using this C code?

  2. Much more importantly, commit 9633be7 now makes a new, BIG logical change: the CMake conditionals totally new and totally different from src/audio/CMakeLists.txt - without a single word of CMake explanation.

What is going on?

zephyr_library_sources_ifdef(CONFIG_COMP_MIXIN_MIXOUT
${SOF_AUDIO_PATH}/mixin_mixout/mixin_mixout.c
${SOF_AUDIO_PATH}/mixin_mixout/mixin_mixout_generic.c
${SOF_AUDIO_PATH}/mixin_mixout/mixin_mixout_hifi3.c
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the conditionals totally different from src/audio/CMakeLists.txt ?!?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we use mmixin_mixout code to achieve the mixing function for IPC4 version and mixer code to achieve the mixing function for IPC3, but the infrastructure and implementation and even ability are very different for those 2 components.

Either the IPC3 "mixer" and the IPC4 "mixin_mixout" are significantly different features that need a different name. Then don't add a new IPC4 COMP_MIXER. Instead a new, IPC4 COMP_MIXIN_MIXOUT option. Keep the single IPC3 COMP_MIXER.

so I think we should better use 2 different kconfig name with the dependence of IPC version for them, and since I move the IPC version dependence into kconfig, we have to change the src/audio/CMakeLists.txt to fit the kconfig modification.

Copy link
Collaborator

@marc-hb marc-hb Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great explanations, thank you! They really deserve to be in the commit message.

and since I move the IPC version dependence into kconfig, we have to change the src/audio/CMakeLists.txt to fit the kconfig modification.

... and as usual in these situations, the problem is: how are you going to TEST all these CMake changes? This requires compiling in many different ways.

Always remember: break it before you fix it. It's very common to edit some of our CMake files while accidentally NOT testing the changes because they're in a different use case or configuration than the current one. If you break it and nothing happens (compilation still works fine), then you're not testing it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's another very useful test trick in C files:

#warning this volume Hifi7 file is being compiled

#error works too.

Copy link
Contributor Author

@andrula-song andrula-song Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually even with the copy/past error, we won't found this mistake because the COMP_MIXER is default yes in mixer folder, we will always compile the mixin_mixout or mixer code based on IPC version(all most all the CI DUTs have pipelines with mixin_mixout now). I noticed this because I want to change mixin_mixout to new hifi config style for hifi5 implementation.

@marc-hb
Copy link
Collaborator

marc-hb commented Feb 1, 2024

we use mmixin_mixout code to achieve the mixing function for IPC4 version and mixer code to achieve the mixing function for IPC3

So once again: how come no one noticed this Kconfig mistake for 2 months? How did you notice it now?

EDIT: answered above in #8791 (comment)

@lgirdwood
Copy link
Member

@andrula-song @marc-hb this looks fine to me. I cant see any blockers here.

@marc-hb
Copy link
Collaborator

marc-hb commented Feb 20, 2024

Last week was all firefighting and Monday was off. I promise I'll look at this again Tuesday first thing.

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • The code change looks good but it is incomplete: please align src/audio/CMakeLists.txt not to ignore your new CONFIG_COMP_*. As already requested by @kv2019i and myself 3 weeks ago, don't leave src/audio/CMakeLists.txt inconsistent with zephyr/CMakeLists.txt

You can easily test src/audio/CMakeLists.txt and Kconfig with commands like these (just an example)

./scripts/docker-run.sh ./scripts/xtensa-build-all.sh rmb
grep MIX build_rmb_gcc/generated/.config 
./scripts/docker-run.sh make -C build_rmb_gcc/ menuconfig
  • The commit title is misleading, this is not just "fixing a kconfig error", this PR is significantly more than that! It's introducing a brand new COMP_MIXIN_MIXOUT that never existed before instead of relying directly on the IPC level. The error that is getting fixed does not even matter much because the fixed code was never used. So that really threw me off for a long time.

  • The commit message is much better now but still too short. Just summarize the answers to the most important questions already discussed. in this PR and add that to the commit message.

  • As requested earlier, Github does not automatically sync the PR title and PR message with the commit title and PR message. It would speed reviews a bit if you could do this manually.

  • To make overbusy reviewers less confused and future reviews much faster, anticipate reviewers questions and answer them in advance in the commit message. This is the purpose of the commit message. https://wiki.openstack.org/wiki/GitCommitMessages

Anticipating reviewers' questions is especially faster when reviews happen across timezones with no possibility of interactive, real-time discussions. Ask teammates in your timezone for a quick review and answer their interactive questions in the commit message Use a metaphorical rubber duck for code reviews: https://en.wikipedia.org/wiki/Rubber_duck_debugging It's not just for debugging.

@lgirdwood lgirdwood marked this pull request as ready for review February 23, 2024 11:44
@lgirdwood
Copy link
Member

  • The code change looks good but it is incomplete: please align src/audio/CMakeLists.txt not to ignore your new CONFIG_COMP_*. As already requested by @kv2019i and myself 3 weeks ago, don't leave src/audio/CMakeLists.txt inconsistent with zephyr/CMakeLists.txt

Lets fix this incrementally as the next step, it better to get this fix in rather than waiting longer.

@lgirdwood lgirdwood dismissed stale reviews from kv2019i and marc-hb February 23, 2024 11:45

Now aligned.

@lgirdwood lgirdwood merged commit 97a50e3 into thesofproject:main Feb 23, 2024
38 of 44 checks passed
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.

4 participants