[RanderWang]

After adding mixer in nocodec topology we got many issues with multi-stream stress test. These issues are related to both kernel or cSOF, and can't be fixed in short time. It will block the coming ipc4 PR test in CI. To prepare for CI and go on debugging these issues, we will support both pass-through and mixer topology.

[plbossart]

No, that's wrong. Keep the mixer and remove the additional branches conditionally.

To repeat myself: PASSTHROUGH PIPELINES ARE NOT ALLOWED FOR ANY PROGRAM

Edit: the only exception is DisplayAudio pipelines (HDMI/DP) where we want to transition to the passthough chain DMA support.

[kv2019i]

Thank you @RanderWang ! I think this will carry us forward until we can rootcause the issues that popup in long test plans with any topology that has mixer included. @ranj063 seems reasonable?

[ranj063]

@RanderWang 2 comments:

1. You should squash the 2 patches.
2. Instead of 2 separate files for nocodec and duplicating everything when really the only difference is the pipelines. we should have a top-level file with the DAI's and PCM's and create&include either cavs-nocodec-mixer-pipelines.conf or cavs-passthrough-nocodec.conf based on a a definition set like this

# include nocodec/mixer-based pipelines 
IncludeByKey.PIPELINE_CONFIG {
	"passthrough"	"cavs-nocodec-passthrough.conf"
	"mixer"		"cavs-nocodec-mixin-mixout.conf"
}

[RanderWang]

@RanderWang 2 comments:

1. You should squash the 2 patches.
2. Instead of 2 separate files for nocodec and duplicating everything when really the only difference is the pipelines. we should have a top-level file with the DAI's and PCM's and create&include either cavs-nocodec-mixer-pipelines.conf or cavs-passthrough-nocodec.conf based on a a definition set like this

# include nocodec/mixer-based pipelines 
IncludeByKey.PIPELINE_CONFIG {
	"passthrough"	"cavs-nocodec-passthrough.conf"
	"mixer"		"cavs-nocodec-mixin-mixout.conf"
}

@ranj063 Thanks! updated

[RanderWang]

@kv2019i very sorry, the root reason is found, please check https://github.com/thesofproject/sof/compare/6106b0817d7267f0d9dcf313c5218a1d738fc929..c573ea79899024949950f6226a14a9aa501ddbfb. The ci test will be failed when the stream 3 is tested, and the first cycles of tests will pass for stream 1 & 2.
I think pass-through pipeline is useful for debug, so I think this PR is still valuable.

[kv2019i]

@plbossart wrote:

No, that's wrong. Keep the mixer and remove the additional branches conditionally.

To repeat myself: PASSTHROUGH PIPELINES ARE NOT ALLOWED FOR ANY PROGRAM

I asked Rander to do this as we have open issues with IPC4 test plans and all configuration with mixer fail (and have done so for many weeks). We have continuous stream of new changes and this is getting impossible. I don't want to have features in mainline that do not work. This makes impossible for me to interpret test results for new PRs that affect code for features that are working in mainline.

So I'm all for this policy. but we need to get the code working first.

[plbossart]

@kv2019i very sorry, the root reason is found, please check https://github.com/thesofproject/sof/compare/6106b0817d7267f0d9dcf313c5218a1d738fc929..c573ea79899024949950f6226a14a9aa501ddbfb. The ci test will be failed when the stream 3 is tested, and the first cycles of tests will pass for stream 1 & 2. I think pass-through pipeline is useful for debug, so I think this PR is still valuable.

I am lost here @RanderWang @kv2019i . If we know what the issue is, where is the PR that fixes the issue?

It's simpler to fix what we have than to revert and redo.

[RanderWang]

sure. Let fix it in another PR