-
Notifications
You must be signed in to change notification settings - Fork 314
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 enhanced audio capture development topologies #9176
Tools: Topology2: Add enhanced audio capture development topologies #9176
Conversation
"line2_68mm" "include/components/tdfb/line2_68mm_pm0_30_90deg_48khz.conf" | ||
"line2_74mm" "include/components/tdfb/line2_74mm_pm0_30_90deg_48khz.conf" | ||
"line4_pass" "include/components/tdfb/line4_pass.conf" | ||
"line4to2_pass" "include/components/tdfb/line4to2_pass.conf" |
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.
Note: For now only pass-through for four DMIC systems for 4ch capture. I don't have yet a 3 beams blob for TDFB but it should be possible. With such we could produce a 3.1 (L, R, C, LFE) or 3.0 format stream in 4ch container. Create of LFE stream is not possible with current TDFB so it would be zero PCM code. I'm not sure if 3.0 format wav is 4ch or 3ch. If 3ch I'm not sure it's possible with SOF. Also I'm not sure how Linux user space handles 4ch streams, does the SOF topology channel map type impact.
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.
Note: The blobs line4to2_pass and line4_generic_pm10deg convert 4ch to 2ch. To use them the topology needs to be set for 2ch PCM for 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.
Slight concern on bisectability, but not a blocker and otherwise looks clean.
@@ -23,7 +23,7 @@ | |||
<mixout-gain-dai-copier-playback.conf> |
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.
Slight concern how the first two interact. If you bisect git and hit the the tree between patches 1&2 in this series, you are left with e.g. SDW topologies without gain on the dmic capture, right?
OTOH, this is pretty minor impact, we rarely bisect topology changes like these and I can understand the separate commits are easier to review.
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.
That's a good point. Please think and let me know, combining patches 1 and 2 would be easy.
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.
@singalsu I'm good with this if not other reasons to revisit the series.
route.1 { | ||
source gain.$index.1 | ||
sink module-copier.$index.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.
shouldn't all the routes be included? Also between the DAI - eqiir - gain?
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.
Yes, agree, I think this is my mistake. Doing it here will clean up top level.
sink 'drc.3.1' | ||
} | ||
{ | ||
source 'drc.3.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.
ok, this is now very explicit and easy to understand: a0->b0, b1->c0, c1->d0, where a, b, and c are objects / components, and 0 and 1 are their sinks and sources, but in other cases it isn't that explicit, so I'm confused.
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.
Yep, that earlier finding looks like my mistake.
sink 'eqiir.4.1' | ||
} | ||
{ | ||
source 'module-copier.4.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.
e.g. here there's no explicit route from eqiir.4.1 to module-copier.4.2 because it's implicit inside the pipeline number 4?
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.
yep
channels_max $DMIC0_PCM_CHANNELS | ||
rate_min $DMIC0_RATE | ||
rate_max $DMIC0_RATE | ||
} |
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.
replacing TABs with spaces?
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.
Doh!
This change prepares for adding it instead to DMIC DAI copier pipeline. There it will control mute/unmute for all possible module copier connected other capture PCMs. The pipeline object gain-capture is replaced with simpler host-gateway-capture. The definition of DMIC0_HOST_PIPELINE_SINK need to be changed from gain to host-copier. With this patch, the typical DMIC capture path looks like: dai-copier --> eqiir --> module-copier --> host-copier Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This change adds volume and switch "Dmic0" into dai-copier pipeline. It ensures that all capture from DMIC follows the mute key control even if some other processing and PCMs are added to module copier. The patch adds a new pipeline class dai-copier-eqiir-gain-module-copier-capture. It is similar as replaced dai-copier-eqiir-module-copier-capture but adds the gain component. The confusing DMIC0_DAI_GAIN (set to eqiir) is removed from all top level topologies (nocodec, rt5682, sdw, hda). After this a typical DMIC0 pipeline looks like: dai-copier --> eqiir --> gain --> module-copier --> host-copier Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This patch updates similarly as for hda-generic the analog capture. Before the patch the capture path pipelines are: dai-copier.HDA.Analog.capture --> host-copier.0.capture After this change: dai-copier.HDA.Analog.capture --> eqiir.4.1 --> module-copier.4.2 --> host-copier.0.capture To use the same dai-copier-eqiir-module-copier-capture tplg code chunk as in hda-generic, the macros HDA_ANALOG_CAPTURE and HDA_ANALOG_PLAYBACK_RATE were added. The addition of IIR to capture mitigates the capture start transients similarly as in hda-generic. This change adds 7.7 MCPS from IIR, and 2.2 MCPS from module-copier in TGL platform. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This change allows to disable and hide the control by omitting name define if it is not useful in the topology. Also other ALSA controls no more require mandatory name. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This patch adds a number of configuration blobs for the time-domain fixed beamformer component. The blobs include pass-through and generic narrow angle stereo beamforming for two and four microphones line array systems. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This patch adds a DRC blob for DMIC capture and renames the speaker blob. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
This patch adds to analog microphone capture pipeline TDFB beamformer and DRC for dynamic range control. The name of updated topology is sof-hda-efx-generic.tplg. Similar capture enhance is added to multi-band DRC version sof-hda-efx-mbdrc-generic.tplg. The pipeline is enabled if HDA_MIC_ENHANCED_CAPTURE is set to true in topologies build. They keys EFX_HDA_MIC_TDFB_PARAMS and EFX_HDA_MIC_DRC_PARAMS control the configurations blobs use. There is no processing applied to capture audio since the topology is built with passthrough blobs. E.g. UCM should set up processing with blobs those have effect. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
4cdb8a7
to
e032bd3
Compare
This patch adds to DMIC0 capture TDFB beamformer and DRC for dynamic range control. The names of updated topologies are sof-hda-efx-generic-2ch.tplg and sof-hda-efx-generic-4ch. The efx topologies with mbdrc are updated similarly. The pipeline is enabled if DMIC0_ENHANCED_CAPTURE is set to true in topologies build. They keys EFX_DMIC0_TDFB_PARAMS and EFX_DMIC0_DRC_PARAMS control the configurations blobs use. Build parameter DMIC0_PCM_CHANNELS controls the number of output channels for beamformer. It is by default two. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
e032bd3
to
450a841
Compare
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.
Maybe I'm missing something and what's really needed is an updated documentation :-)
route.2 { | ||
source eqiir.$index.1 | ||
sink gain.$index.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.
the route from eq-iir to the DAI isn't needed?
@@ -289,7 +336,7 @@ IncludeByKey.PASSTHROUGH { | |||
Object.Base.route [ | |||
{ | |||
source $DMIC0_DAI_COPIER | |||
sink $DMIC0_DAI_GAIN | |||
sink eqiir.$DMIC0_DAI_PIPELINE_ID.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.
not saying that this is wrong, I must be missing something about how these routes should be added. I see 4 "widgets" in this pipeline: DAI copier, module copier, eq-iir and gain, and I see only 2 connections: from the DAI copier to eq-iir (not to the module copier?) and apparently from this whole DAI pipeline to a host sink pipeline. No need for all the other routes?
SOFCI TEST |
SOFCI TEST |
@singalsu this isn't touching Zephyr build failures, everything else look OK. |
Example of sof-hda-efx-generic.tplg
Example of sof-hda-efx-generic-2ch.tplg
In HDA analog capture the beamformer are configured to always be in passthrough mode. User switch controls have no impact. A processing blob that enhances audio must be set up by ALSA UCM.
In DMIC 2ch the beamformer is set up for very small stereo opening angle for user focus. In DMIC 4ch the beamformer is always passthrough. UCM could be set up to apply beams for 3.0 or 3.1 format as 4ch but it's not yet available. There is also topology sof-hda-efx-generic-4to2ch.tplg that always converts to 2ch, beam off is channels 1 and 4 passthrough. Beam on is stereo beams with 4 mic.
In HDA analog capture the DRC is configured to passthrough. User switch controls have no impact. The ALSA UCM needs to apply a blob to get processing for notebook speaker mode.
In DMIC capture the DRC is set up to 10 dB soft amplification.
There is a small change done to every DMIC capture pipeline (using platform/intel/dmic-generic.-conf). The gain component is moved before module-copier. It ensures that every new pipeline connected to module-copier follows the mic mute keys control. See e.g. sof-hda-generic-2ch.tplg.