-
Notifications
You must be signed in to change notification settings - Fork 322
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
topology2 : add DTS topology and changes for MTL #8378
Conversation
e235b4f
to
f7bf6c4
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.
LGTM, just a question about index.
# playback pipelines | ||
host-copier-gain-mixin-playback [ | ||
{ | ||
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.
@jsarha @bardliao @plbossart do we still need index, IIRC we were (planning?) removing index from topology to be automatic.
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.
@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.
} | ||
] | ||
|
||
mixout-gain-dai-copier-playback [ |
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.
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?
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.
I have one question. For "insert" you mentioned, do you mean using IncludeByKey to choose different pipeline or route at the top-level?
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.
Ack, I think @ranj063 was referring to IncludeByKey here.
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.
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 [ |
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.
Ack, I think @ranj063 was referring to IncludeByKey here.
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" { |
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.
add comments for what's table used for?
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.
This table is the initial parameters to DTS library.
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.
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?
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.
@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.
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 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]}
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.
@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"
'''
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.
@johnylin76 Updated the table now.
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 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]>
f7bf6c4
to
ab9b233
Compare
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]>
ab9b233
to
bd7ddd6
Compare
@@ -0,0 +1,148 @@ | |||
Object.Base.data."dts_spk" { |
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 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.
The ipc3-stub build failure is unrelated, proceeding with merge. |
Add DTS topology and related changes for MTL with rt5682. Will enable DTS later until rt5650 is ready.