topology2: mtl-rt5650: Add configuration for AEC w/o DTS #9240
Conversation
| BT_NAME=SSP1-BT,BT_INDEX=1,BT_ID=7,BT_PCM_NAME=Bluetooth,INCLUDE_ECHO_REF=true,\ | ||
| GOOGLE_RTC_AEC_SUPPORT=1,DEEP_BUF_SPK=true,PLAYBACK_PIPELINE_SRC=volume,\ | ||
| SSP_SPK_FMT_24=true,SSP_HS_FMT_24=true" | ||
|
|
There was a problem hiding this comment.
is this really a 'production' topology? I am starting to think a lot of those topologies are for test and development, and don't need to be handled in this folder.
There was a problem hiding this comment.
Ack,, @andyross @cujomalainey that's a good question. The topologies in production are going to be shipped via sof-bin and e.g. included verbatim to many Linux distributions. Rationale is to ship all topologies we refer to in upstream Linux kernel. There are some exceptions due to historical reasons, but target is to distribute all the files in production folder. This is Intel only now, but all vendors are really welcome to add their binaries to the sof-bin releases and we are keeping the process that way on purpose.
If you have topologies that are only for development, we have a separate "topology2/development" folder.
There was a problem hiding this comment.
Is the suggestion to move it to ../development/tplg-targets.cmake? I can do that. (Though there's some practical friction there as scripts/build-tools.sh -T won't build non-production topologies by default, meaning you can't have a "test" that uses the same build scripting as "production").
I guess the counterargument is maintenance: this is all boilerplate, and you want repeated boilerplate to live next to its "siblings" where possible so that when someone comes by to change something they don't miss one. IMHO "production" and "development" are the wrong axes here and we want to be grouping by platform. Which I guess we are, as this is an ace file.
But I'll move it if you want.
There was a problem hiding this comment.
I'm neutral on this, just that if if it's under "production/", it's going to be shipped out.
Plain "scripts/build-tools.sh" will build the development topologies as well. Not sure why the "-T" has been special cased, but that indeed is the case.
There was a problem hiding this comment.
Maybe a better scheme would be to keep the topology descriptors (or whatever the cmake entries are called) in a hierarchy that reflects their commonality and keep a separate registry of "topologies to ship to sof-bin" by name somewhere else?
There was a problem hiding this comment.
@andyross we can move it back if we start shipping it, which is quite possible in the future
Combinatorics get hard with all the features, but it's really useful to be able to test features in isolation. Signed-off-by: Andy Ross <andyross@google.com>
|
Moved. Though I fear this is likely to be broken the next time someone touches the default MTL topologies, as none are in the development tree. |
Combinatorics get hard with all the features, but it's really useful to be able to test features in isolation.