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

topology2 : add DTS topology and changes for MTL #8378

Merged

Conversation

joechengxperi
Copy link
Contributor

Add DTS topology and related changes for MTL with rt5682. Will enable DTS later until rt5650 is ready.

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, just a question about index.

# playback pipelines
host-copier-gain-mixin-playback [
{
index 1
Copy link
Member

Choose a reason for hiding this comment

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

@jsarha @bardliao @plbossart do we still need index, IIRC we were (planning?) removing index from topology to be automatic.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@lgirdwood yes it is still needed. There's no plan to make it automatic right now because widgets are identified with the index for top-level routes.

@lgirdwood lgirdwood added this to the v2.8 milestone Oct 25, 2023
}
]

mixout-gain-dai-copier-playback [
Copy link
Collaborator

@ranj063 ranj063 Oct 25, 2023

Choose a reason for hiding this comment

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

this seems a bit too much duplication. Can we simplify this by moving the mixout-gain to a separate pipeline and connecting to the DAI copier at the top-level first? And then add a new pipeline with just the eq-iir->dts and insert it only when needed along with the new routes at the top-level?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have one question. For "insert" you mentioned, do you mean using IncludeByKey to choose different pipeline or route at the top-level?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ack, I think @ranj063 was referring to IncludeByKey here.

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.

Ranjani and Jyri are the experts with a change like this, but a few comments from me as well. Mostly looks good, one smaller thing and then the question of how much existing definitions can be reused.

}
]

mixout-gain-dai-copier-playback [
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ack, I think @ranj063 was referring to IncludeByKey here.

tools/topology/topology2/cavs-rt5682.conf Show resolved Hide resolved
@joechengxperi
Copy link
Contributor Author

Ranjani and Jyri are the experts with a change like this, but a few comments from me as well. Mostly looks good, one smaller thing and then the question of how much existing definitions can be reused.

host-copier-gain-mixin-playback is duplicated. For mixout-gain-dai-copier-playback and mixout-gain-eqiir-dts-dai-copier-playback, dai copier and gain are duplicated. This is the question Ranjani asked.

I roughly have an idea to use IncludeByKey to implement Ranjani's suggestion. The difficult part is to just insert eq iir -> dts only. But the structure might become a little bit complicate comparing to current patch having two mixout-gain pipeline.

And I'm curious about the importance to avoid duplication here. I had two versions of top-level topology at the beginning. The first one is more likely to follow cavs-nocodec.conf. And the second is to follow sof-hda-generic.conf. Comparing these two version, I think sof-hda-generic.conf is more easy to read and could add more playback pipelines easily if necessary. But the drawback is too much duplication.

@@ -0,0 +1,148 @@
Object.Base.data."dts_spk" {
Copy link
Contributor

Choose a reason for hiding this comment

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

add comments for what's table used for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This table is the initial parameters to DTS library.

Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like a full-spec config, which should be set from external rather than by default.
Why don't we use an empty config for default similar to topology1?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@johnylin76 Yes, this is the full config with default parameters for DTS library. To use empty config or not set the parameters lead to some problems here. Instead, to put the default parameters here works fine. We'll still need to set the parameters by UCM afterward since it varies by project.

Copy link
Contributor

Choose a reason for hiding this comment

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

The empty config I meant is the ABI-header-only blob, e.g. https://github.com/thesofproject/sof/blob/cavs2.5-001-drop-stable/tools/topology/topology1/m4/dts_codec_adapter.m4#L5

bytes "
0x53,0x4f,0x46,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0xa0,0x01,0x03,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00"

Have you tried this config and still led to problems?

I think we can set the full config here for developing purposes, but should not push this to upstream. Instead, a minimal and least effective config as default is preferred.

p.s. if the config above doesn't work, maybe try this instead:

bytes "
0x53,0x4f,0x46,0x00,0x00,0x00,0x00,0x00,
0x0c,0x00,0x00,0x00,0x00,0xa0,0x01,0x03,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x0c,0x00,0x00,0x00,
0x00,0x00,0x00,0x00"

which contains a 12-byte module config {paramId=0, paramSize=0xc, paramData=[0x0]}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@johnylin76
I tried both of them before. They didn't work. But I notice a minor difference here now that makes the second one work. I'll test it further and update it.

bytes "
0x53,0x4f,0x46,0x34,0x00,0x00,0x00,0x00,
0x0c,0x00,0x00,0x00,0x00,0xa0,0x01,0x03,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x01,0x00,0x00,0x00,0x0c,0x00,0x00,0x00,
0x00,0x00,0x00,0x00"
''' 

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@johnylin76 Updated the table now.

Copy link
Contributor

Choose a reason for hiding this comment

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

The updated bytes will pass a param entry {paramId=1, paramSize=0xc, paramData=[0x0]} to DTS library. Given that paramId=1 is used in the full config, which should be the effective param ID for DTS library.

My previous idea is to pass {paramId=0, paramSize=0xc, paramData=[0x0]} which avoids the effective ID for DTS. However it sounds that errors are produced by paramId=0.

As long as DTS library has no side effect by setting {paramId=1, paramSize=0xc, paramData=[0x0]}, that looks good to me.

This commit adds DTS componenet and pipeline for topology2.
1. DTS component
2. A new pipeline to support EQ IIR + DTS processing

dts_spk.conf includes the parameters for DTS SDK V1.1.3

Co-developed-by: Mac Chiang <[email protected]>
Signed-off-by: Mac Chiang <[email protected]>
Signed-off-by: Joe Cheng <[email protected]>
@joechengxperi joechengxperi force-pushed the main-dts-mtl-tplg-split-2-1 branch from f7bf6c4 to ab9b233 Compare November 3, 2023 02:15
In order to adopt more different playback pipelines, refer to
sof-hda-generic.conf and move playback pipeline in cavs-rt5682.conf to
cavs-mixin-mixout-ssp.conf.

Co-developed-by: Mac Chiang <[email protected]>
Signed-off-by: Mac Chiang <[email protected]>
Signed-off-by: Joe Cheng <[email protected]>
Add cavs-mixin-mixin-mixout-eqiir-dts-ssp.conf to support EQ IIR + DTS
processing on rt5682

Co-developed-by: Mac Chiang <[email protected]>
Signed-off-by: Mac Chiang <[email protected]>
Signed-off-by: Joe Cheng <[email protected]>
@joechengxperi joechengxperi force-pushed the main-dts-mtl-tplg-split-2-1 branch from ab9b233 to bd7ddd6 Compare November 3, 2023 03:18
@@ -0,0 +1,148 @@
Object.Base.data."dts_spk" {
Copy link
Contributor

Choose a reason for hiding this comment

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

The updated bytes will pass a param entry {paramId=1, paramSize=0xc, paramData=[0x0]} to DTS library. Given that paramId=1 is used in the full config, which should be the effective param ID for DTS library.

My previous idea is to pass {paramId=0, paramSize=0xc, paramData=[0x0]} which avoids the effective ID for DTS. However it sounds that errors are produced by paramId=0.

As long as DTS library has no side effect by setting {paramId=1, paramSize=0xc, paramData=[0x0]}, that looks good to me.

@kv2019i
Copy link
Collaborator

kv2019i commented Nov 3, 2023

The ipc3-stub build failure is unrelated, proceeding with merge.

@kv2019i kv2019i merged commit 244df9f into thesofproject:main Nov 3, 2023
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.

7 participants