[akloniex]

In order to handle complex topologies, we need more precise control
over connected pipelines behaviour and propagation of events.
Better control is accomplished by limiting propagation of events in
case of mismatch between starting and desination pipelines that are
connected, for example when propagating from playback pipeline to branch
which endpoint is Host component, or reversely, when propagating from
capture pipeline to one with Dai endpoint.

Signed-off-by: ArturX Kloniecki arturx.kloniecki@linux.intel.com

This PR was extracted from #1275

[tlauda]

@akloniex @lgirdwood @plbossart In general I'm a fan of such solution to treat every pipeline independently, but unfortunately currently it will break mixer topologies. We won't be able to start media pipeline, because params won't be propagated to mixer ppl.

[xiulipan]

@tlauda @akloniex @lgirdwood @plbossart
I think we should have some discussion about the params propagated.
Volume component can covert the format.
Src component can covert the Rate

@tlauda and I have some discussion about this few month ago and we did not have any idea.
If we have a mixer in topology (actually now is the low latency playback we have in sof-byt-codec.m4)

# PCM0 ----> volume0.1 ------------------+
#                                        |--low latency mixer ----> volume0.2 ---->  SSP2
# PCM1 -----> volume1.1 ----> SRC1.1 ----+

If we have SSP2 set to be S16LE with 48K, what can we play on PCM0 and what can we play on PCM1?

Now image a situation:
PCM0: S32LE 48K
PCM1: S24LE 16K

what should be the source/sink prams for each buffer
here is my guess:

PCM0, HOST0 -- S32LE 48K -- VOL0.1 -- S32LE 48K --------------------------mixer -- S32LE 48K --VOL0.2 --S16LE 48K -- SSP2
PCM1, HOST1 -- S24LE 16K -- VOL1.1 -- S32LE 16K -- SRC1.1 -- S32LE 48K--+

And I can also have something like:

PCM0, HOST0 -- S32LE 48K -- VOL0.1 -- S16LE 48K --------------------------mixer -- S16LE 48K --VOL0.2 --S16LE 48K -- SSP2
PCM1, HOST1 -- S24LE 16K -- VOL1.1 -- S16LE 16K -- SRC1.1 -- S16LE 48K--+

Any idea about what should be and how we handle the mixer involved pipelines?

[plbossart]

We are going to shoot us in the foot if we keep thinking in terms of continuity between FE and BE, and preloading the data from the host all the way to the DAI. The mixer may want need to remain operational and generate zeroes even in the absence of any stream. This is a classic case that is implemented by all sound servers so as to avoid pops and clicks. It's pretty common to leave the mixer/interface on for a while before deciding to tear things down.
The use of a mixer means we need to make sure all the streams connected into the mixer are resampled and volume-controlled prior to mixing. The mixer should be as dumb as possible, and fancy solutions with a soft-limiter to prevent clipping should be done when the simple case has been dealt with.
A good way to progress would be to STOP including mixers in the middle of the low-latency pipeline, but rather to view them as a start of a new pipeline. The current approach is based on the "Broadwell" way of doing things and it's been obsolete for several years. We should really use the more modern concepts used for Baytrail/Cherrytrail and Intel Skylake+ solutions. There are practical cases where we need to feed the same streams on multiple outputs, and currently our topologies and triggering schemes prevent that from happening

[lgirdwood]

@xiulipan feature request #1280 explains how to propagate params from PCM downstream, but it does need to use a endpoint to endpoint terminology as @plbossart has mentioned rather than always FE to BE.

[lgirdwood]

@akloniex also please see #1280

[xiulipan]

@lgirdwood
I will take a look at that feature.

[keyonjie]

let's verify if this can be the replacement for #1365, to make KWD work. @keqiaozhang @wwittbrx

[keyonjie]

@akloniex We might need stop propagation of pipeline trigger for different pipelines also, otherwise, KWD pipelines doesn't work, can you update your PR with that, please?

[keyonjie]

since #1365 is merged, so I am fine if you don't add stop propagation of pipeline trigger to this PR.

[jajanusz]

@akloniex @keyonjie So is it needed or not? TBH I'd like it to be independent as possible (as @tlauda wrote), but if it going to break things then it should be done somehow differently (f.e. with some fix for mixer in the same pr etc).

[juimonen]

@jajanusz @akloniex I understand the direction where this is driven, but triggering and propagating params for separate connected pipelines will not happen from driver side with this schedule (this week). So as you said, we need to then fix the mixer&demux to be intelligent enough to do the proper thing...

[keyonjie]

@akloniex @keyonjie So is it needed or not? TBH I'd like it to be independent as possible (as @tlauda wrote), but if it going to break things then it should be done somehow differently (f.e. with some fix for mixer in the same pr etc).

I prefer we do this later to avoid breaking any existed e.g. mixer component, the logic to me is that switching to better framework when it is ready, before that, suffer it. :)

[akloniex]

@jajanusz @lgirdwood
It is needed to properly handle change of direction between connected pipelines in Echo Reference topology. Without it, capture pipeline attached to demux component is overwritten with playback parameters (direction including) which leads to misconfiguration.
Prepare and reset propagation is stopped to unify behaviour with the params change. I'm working on verifying if adding trigger to the package won't break anything.

Regarding Mixer topologies that are broken with this change, I will talk with @tlauda today to check how we can bypass the issues there.

[akloniex]

@lgirdwood @jajanusz @tlauda
I've updated the PR, to only stop propagation of pipeline ops when branching pipelines have direction that would be incompatible with endpoint component types.

[juimonen]

@akloniex cool! I was just experimenting with the same direction.... does it work? :)

[juimonen]

@akloniex there's a typo in your code, so this doesn't compile...
But... if I fix that typo, I can play/capture with echo ref pipeline, but also with basic apl mixer pipeline.
So works for me!

[jajanusz]

@lgirdwood @tlauda @mmaka1 ping

[juimonen]

@keyonjie also to see this works with kwd...

[keyonjie]

@juimonen @akloniex I verified this works with kwd also, thanks.

[jajanusz]

@lgirdwood @tlauda @mmaka1 ping, we need more reviews

[mmaka1]

A simple test for direction change and pipeline id change to stop the propagation could fix it I guess and if I understand it correctly, the direction is the property that might be unavailable (not configured yet) while propagating and this is the reason why it tries to test the component type?

[akloniex]

@mmaka1
Exactly that is the reason. Direction property might not yet be configured in the pipeline we're propagating to. Kernel flow is to parametrize and prepare one pipeline and the proceed to the next one, which would lead to propagation of params call, parametrization of branched pipeline with wrong direction, and during prepare call, direction parameter would still be unreliable, since wrong direction would've been propagated or not configured yet.