[macchian]

Enabling dts pipeline on HDA0 speaker/headphone playaback.
In this case, using defined macro W_PIPELINE_TOP() to add missing dai pipeline is due to topology not found it for PCM0P.
Verified dts test blobs via sof-ctl.

[kv2019i]

Can we upstream this to stable-v2.2 branch as well to keep that in sync?

[plbossart]

I have mixed feelings about this, all existing HDaudio topologies don't have any processing, so new topologies with processing should be handled in a well-identified block. @singalsu was also working on changes to HDaudio, we should place all 'enhanced' topologies together IMHO.

At a minimum this should be a different comment block, worst-case a different file.

[macchian]

@plbossart , please correct me if I misunderstand your suggestions. After reading the singalsu's PR, I think new hda file with process.m4 could be a source topology for all other 3P codecs directed pipe.

So create a new file e.g. sof-hda-generic-pproc.m4 (copy from sof-hda-generic.m4 with fixed missing pipe here. Currently this way might be worst case.

+"sof-hda-generic-pproc;sof-hda-generic-pproc-dts;-DCHANNELS=4;-DHSPROC=volume;-DDMICPROC_FILTER1=eq_iir_coef_highpass_40hz_20db_48khz.m4;-DDMIC16KPROC_FILTER1=eq_iir_coef_highpass_40hz_20db_16khz.m4;-DDYNAMIC=1;-DPPROC=pipe-eq-iir-dts-codec-playback.m4"

[plbossart]

@macchian the point is that DTS is not an open-sourced library that is distributed as part of sof-bin, so we want this topology to be identified and not released by sof-bin (or released in a very clear directory that says CHROME_ONLY or something).

Adding @marc-hb for further comments.

[lgirdwood]

This is needed for Chrome cavs-2.5 and main (tplg2) branches but not needed in stable-v2.2.

[lgirdwood]

@macchian do you have a similar PR with enhanced HDA for main branch ? We cant use 3P for HDA main, but we can use EQ and other open modules. Please work with @singalsu when he is back next week on module/pipeline definition (that can also be used in CI) around HDA. Thanks !
@lgirdwood , no, I don't have it on main branch. In this case it needs on cavs2.5. On main branch, I might need to consult @singalsu how to use EQ as a similar example as you mentioned.

[marc-hb]

the point is that DTS is not an open-sourced library that is distributed as part of sof-bin, so we want this topology to be identified and not released by sof-bin
Adding @marc-hb for further comments.

This is needed for Chrome cavs-2.5 and main (tplg2) branches but not needed in stable-v2.2.

It is also my understanding that this cavs25 branch will never be released to sof-bin.

Now we should probably still have a good answer to @plbossart for the longer term (new subdirectory?) but not needed in the cavs2.5 branch AFAIK.

Even if it were accidentally released to sof-bin, how much damage would that do?

[plbossart]

I will assert that all topologies released in sof-bin should be compatible with firmware released in sof-bin. Otherwise, there's a risk of someone loading a topology that will result in an IPC error when trying to access a non-existent module.

So while I have no objection to the notion of adding more topologies in main for Chrome or others to make downstream project management easier, I kindly request that they be managed separately instead of the same directory and Cmake file.

[lgirdwood]

cavs-2.5 branch is downstream Chrome so not in sof-bin.
We can make sure a similar PR for main uses the EQ (or similar open module) as an example module.

[marc-hb]

Otherwise, there's a risk of someone loading a topology that will result in an IPC error when trying to access a non-existent module.

Is a kernel parameter the only way to attempt this?

[lgirdwood]

@mwasko fyi - HDA processing topology for CAVS-2.5.

[lgirdwood]

Adding @abonislawski since @mwasko is out.