Tools: Topology1: Fix topologies build with new alsa-lib#10598
Tools: Topology1: Fix topologies build with new alsa-lib#10598singalsu wants to merge 1 commit intothesofproject:mainfrom
Conversation
This patch fixes build error with alsa-lib commit 541427761292.
ALSA lib ops.c:47:(lookup_ops) [error.topology] wrong kcontrol
ops value string ''
It impacts build of sof-mt8195-mt6359-max98390-rt5682-rtnr.tplg
and sof-mt8195-mt6359-max98390-rt5682-google-aec-rtnr.tplg.
In the created .conf from m4 conversion, the value of put is
an empty string in SectionControlBytes.
# control uses bespoke driver get/put/info ID for ext ops
extops."extctl" {
thesofproject#258 binds the mixer control to bytes get handlers
get "258"
put ""
}
The use of m4 macro CONTROLBYTES_OPS() requires three parameters
while originally there was only two. All other usages of
CONTROLBYTES_EXTOPS() in SOF are with 258, 258 as 2nd and 3rd
parameters, so it is assumed it should be same for RTNR
controls also.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
There was a problem hiding this comment.
Pull request overview
Fixes topology1 build breakages with newer alsa-lib by ensuring RTNR byte controls provide valid ext ops (non-empty put), avoiding invalid kcontrol ops strings during topology conversion/build.
Changes:
- Update RTNR
CONTROLBYTES_EXTOPS()usages to pass bothgetandputop IDs (258, 258) where previously theputargument was missing. - Apply the fix to both the standard RTNR capture pipeline and the Google RTC audio processing RTNR capture pipeline.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tools/topology/topology1/sof/pipe-rtnr-google-rtc-audio-processing-capture.m4 | Fix RTNR readonly bytes control extops to provide non-empty put op ID for alsa-lib compatibility. |
| tools/topology/topology1/sof/pipe-rtnr-capture.m4 | Fix RTNR readonly bytes control extops to provide non-empty put op ID for alsa-lib compatibility. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| C_CONTROLBYTES_READONLY(DEF_RTNR_BYTES, PIPELINE_ID, | ||
| CONTROLBYTES_OPS(bytes, 258 binds the mixer control to bytes get handlers, 258), | ||
| CONTROLBYTES_EXTOPS(258 binds the mixer control to bytes get handlers, 258), | ||
| CONTROLBYTES_EXTOPS(258 binds the mixer control to bytes get handlers, 258, 258), |
There was a problem hiding this comment.
The comment string passed to CONTROLBYTES_EXTOPS says this control binds to "bytes get handlers", but the macro invocation now provides both get and put IDs (258, 258). Update the comment text to reflect get/put (or switch to CONTROLBYTES_EXTOPS_READONLY if this is intended to be get-only) so the generated .conf comments remain accurate.
| CONTROLBYTES_EXTOPS(258 binds the mixer control to bytes get handlers, 258, 258), | |
| CONTROLBYTES_EXTOPS(258 binds the mixer control to bytes get/put handlers, 258, 258), |
This patch fixes build error with alsa-lib commit 541427761292.
ALSA lib ops.c:47:(lookup_ops) [error.topology] wrong kcontrol ops value string ''
It impacts build of sof-mt8195-mt6359-max98390-rt5682-rtnr.tplg and sof-mt8195-mt6359-max98390-rt5682-google-aec-rtnr.tplg.
In the created .conf from m4 conversion, the value of put is an empty string in SectionControlBytes.
The use of m4 macro CONTROLBYTES_OPS() requires three parameters while originally there was only two. All other usages of CONTROLBYTES_EXTOPS() in SOF are with 258, 258 as 2nd and 3rd parameters, so it is assumed it should be same for RTNR controls also.