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

Tools: Topology2: Add build of 1ch DMIC topologies #9763

Merged
merged 4 commits into from
Jan 22, 2025

Conversation

singalsu
Copy link
Collaborator

@singalsu singalsu commented Jan 3, 2025

No description provided.

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

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

LGTM. @bardliao @ranj063 pls review.

@singalsu singalsu marked this pull request as ready for review January 7, 2025 12:05
@@ -16,6 +16,8 @@ EFX_HDA_MIC_TDFB_PARAMS=line2_pass,EFX_HDA_MIC_DRC_PARAMS=passthrough"
# HDA topology with mixer-based pipelines for HDA and
# passthrough pipelines for HDMI and
# 2 or 4 DMIC, no NHLT blob included in topology
"sof-hda-generic\;sof-hda-generic-1ch\;HDA_CONFIG=mix,NUM_DMICS=1,PDM0_MIC_B_ENABLE=false"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should PDM0_MIC_B_ENABLE be 0 instead of false?
And do we need DMIC0_ENHANCED_CAPTURE for the topologies?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, 0 / 1 seems to be more common. Then maybe better to change.

I dropped DMIC0_ENHANCED_CAPTURE because the beamformer doesn't support mono. The 1ch version would need a topology variant with only DRC. I'd propose to fix this in two steps, first without DRC, and after that add the DRC.

@singalsu singalsu marked this pull request as draft January 7, 2025 13:46
@singalsu
Copy link
Collaborator Author

singalsu commented Jan 7, 2025

Converting to draft, there's a topology build issue. Likely after I added similar DMIC1 stuff and didn't fully rebuild.

@singalsu singalsu force-pushed the tplg_dmic_1ch branch 2 times, most recently from 854a60c to cf6c37e Compare January 7, 2025 15:51
@singalsu singalsu marked this pull request as ready for review January 8, 2025 17:32
@singalsu
Copy link
Collaborator Author

singalsu commented Jan 8, 2025

Changed back to proposal, my test with MTL worked.

@lgirdwood
Copy link
Member

@singalsu can you rebase/force push again to get CI to rebuild with disk space fix.

This patch adds to dmic-generic.conf for Intel platforms the
mono audio formats for DAI copier, host copier, module copier,
IIR equalizer, and gain.

The earlier version of this file could not handle the case
NUM_DMICS equals 1.

Signed-off-by: Seppo Ingalsuo <[email protected]>
@singalsu singalsu marked this pull request as draft January 10, 2025 16:13
This patch adds the mono formats to dmic1-passthrough.conf for
Intel platforms. It also fixes failing capture issue happening
due to kernel formats handling changes.

The formats are now introduced per NUM_DMICS to avoid kernel
DMIC blob format select logic to be unable to select. The
rate_min/max is replaced by rates.

Signed-off-by: Seppo Ingalsuo <[email protected]>
This patch adds the missing mono formats to dmic1-mfcc.conf
for Intel platforms.

Signed-off-by: Seppo Ingalsuo <[email protected]>
This patch adds build of topologies
- sof-hda-generic-1ch
- sof-hda-generic-cavs25-1ch
- sof-hda-generic-ace1-1ch
- sof-hda-generic-ace3-1ch

The three latter topologies contain the NHLT blob for DMIC
setup. The first one requires that BIOS NHLT contains the
mono DMIC setup.

The macro PDM0_MIC_B_ENABLE need to be set to zero for
alsa-utils to be able to create a valid mono DMIC blob.

Signed-off-by: Seppo Ingalsuo <[email protected]>
@singalsu singalsu marked this pull request as ready for review January 10, 2025 17:39
@singalsu
Copy link
Collaborator Author

The alsa-utils update is needed for MTL and successive platforms to correctly set up mono FIFO, see alsa-project/alsa-utils#286 .

@kv2019i
Copy link
Collaborator

kv2019i commented Jan 14, 2025

I'm a bit at loss how do we track the alsa-utils dependency after we merge this PR. I can already see myself releasing SOF 2.13 without checking the builder making the tplg binaries has the correct alsa-utils and potentially ship invalid 1ch tplg binaries.

Maybe file an issue that once the alsa-utils patch is merged and the github public SOF docker is update, we make a change to tools to make this is a hard dependency (tplg2 build will fail if alsa-utils is too old). Better ideas anyone?

@lgirdwood
Copy link
Member

lgirdwood commented Jan 14, 2025

I'm a bit at loss how do we track the alsa-utils dependency after we merge this PR. I can already see myself releasing SOF 2.13 without checking the builder making the tplg binaries has the correct alsa-utils and potentially ship invalid 1ch tplg binaries.

Maybe file an issue that once the alsa-utils patch is merged and the github public SOF docker is update, we make a change to tools to make this is a hard dependency (tplg2 build will fail if alsa-utils is too old). Better ideas anyone?

Use west to locally add alsa-lib and alsa-utils as a module and locally install in $HOME/work/sof

@singalsu
Copy link
Collaborator Author

I'm a bit at loss how do we track the alsa-utils dependency after we merge this PR. I can already see myself releasing SOF 2.13 without checking the builder making the tplg binaries has the correct alsa-utils and potentially ship invalid 1ch tplg binaries.
Maybe file an issue that once the alsa-utils patch is merged and the github public SOF docker is update, we make a change to tools to make this is a hard dependency (tplg2 build will fail if alsa-utils is too old). Better ideas anyone?

Use west to locally add alsa-lib and alsa-utils as a module and locally install in $HOME/work/sof

Local alsa, if git master version, can be at times tricky to compile. But if download some specific release or git hash for build then should be more predictable. We have had with all new platforms problems with not everyone having latest alsa. Including our own CI system.

Minimum version check with cmake would make a coarse filter for using system alsa, I'm now at v1.2.13, so once the ACE 1ch fix is merged and new release is made min. would be v1.2.14. Not sure what would be the best way here.

@lgirdwood
Copy link
Member

I'm a bit at loss how do we track the alsa-utils dependency after we merge this PR. I can already see myself releasing SOF 2.13 without checking the builder making the tplg binaries has the correct alsa-utils and potentially ship invalid 1ch tplg binaries.
Maybe file an issue that once the alsa-utils patch is merged and the github public SOF docker is update, we make a change to tools to make this is a hard dependency (tplg2 build will fail if alsa-utils is too old). Better ideas anyone?

Use west to locally add alsa-lib and alsa-utils as a module and locally install in $HOME/work/sof

Local alsa, if git master version, can be at times tricky to compile. But if download some specific release or git hash for build then should be more predictable. We have had with all new platforms problems with not everyone having latest alsa. Including our own CI system.

Yes - that's exactly what west would do. You pick a commit that works and use it, then update when needed.

@kv2019i kv2019i merged commit c6a6e17 into thesofproject:main Jan 22, 2025
47 of 49 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