[FEATURE] Improve parameter refinement within pipelines.

[lgirdwood]

Is your feature request related to a problem? Please describe.
Host drivers and userspace will pass PCM rates, formats and channels to the DSP when opening a stream. This currently require topology to match the DAI configuration to the userspace configuration and does not give much scope for refinement within the pipeline.

See https://github.com/orgs/thesofproject/teams/sof-developers/discussions/9

Describe the solution you'd like
We currently define pipelines that can accept a range of runtime params (like rate, channels, format) via the host component (as this component has the 1:1 driver connection). We do need to pass these params and any modifications (that components make) downstream from source to sink. i.e. this can be done by walking the graph in 3 passes

1. check the connected DAI for multiple configs and match to any hw_params.

2. Walk from DAI to all other endpoints setting component params to match hard coded DAI params.

At this point each component has a copy of the DAI params locally for each of it sources and sinks.

3. Walk from host to all other endpoints and refine the params from the host sink/source to the DAI params.

Additional context - Examples

host (44.1kHz) -> volume -> DAI (48kHz)

Passes 1& 2 for the above pipeline would populate all the components (except host) with 48kHz rate.
Pass 3 would try and see where this rate could be converted from 44.1kHz to 48 kHz. i.e it would set volume to 44.1kHz but would ultimately fail as there would be no way to change the DAI to 44.1kHz.

host (16bit) -> volume -> DAI (24bit)

The same pipeline, but this time refining the format. Passes 1 & 2 sets all formats to 24 bit (except host).
Pass 3 Sets volume to 24 bit (which succeeds as volume can convert 16 -> 24bit).

The same algorithm would also be applicable to larger pipelines with multiple differences between host and DAI. They key thing is that topology permits the different params to allow the refinement within the pipeline.

We are currently missing passes 1 & 2 today.

[lgirdwood]

@mengdonglin @michalgrodzicki this is P1 for SOF v1.4. @tlauda fyi, this should make sure all params will be set correctly or fail gracefully.

[lgirdwood]

@singalsu @keyonjie fyi.

[lgirdwood]

Changes required at buffer/component level are

diff --git a/src/include/sof/audio/buffer.h b/src/include/sof/audio/buffer.h
index 1f4803bd..53392c7f 100644
--- a/src/include/sof/audio/buffer.h
+++ b/src/include/sof/audio/buffer.h
@@ -82,6 +82,13 @@ struct comp_buffer {
        int cb_type;
 
        spinlock_t lock; /* component buffer spinlock */
+
+       /* runtime stream config */
+       uint32_t frame_fmt;     /**< enum sof_ipc_frame */
+       uint32_t buffer_fmt;    /**< enum sof_ipc_buffer_format */
+       uint32_t rate;
+       uint16_t channels;
+       uint16_t chmap[SOF_IPC_MAX_CHANNELS];
 };
 
 #define buffer_comp_list(buffer, dir) \
diff --git a/src/include/sof/audio/component.h b/src/include/sof/audio/component.h
index 4cd446f3..6653776f 100644
--- a/src/include/sof/audio/component.h
+++ b/src/include/sof/audio/component.h
@@ -242,9 +242,6 @@ struct comp_dev {
        uint32_t frame_bytes;      /**< frames size copied to sink in bytes */
        struct pipeline *pipeline; /**< pipeline we belong to */
 
-       /** common runtime configuration for downstream/upstream */
-       struct sof_ipc_stream_params params;
-
        /** driver */
        struct comp_driver *drv;

[lgirdwood]

@michalgrodzicki @wenqingfu Fyi, this needs to be implemented soon as it's the basis for many complex use cases. I'm not seeing any movement on this, but do see developers raising issues that can be fixed by this.

[tlauda]

@lgirdwood @akloniex @keyonjie @juimonen
I don't see how it handles the logic of choosing if we should propagate the params to the connected pipelines or not. Let's take mux topology with the loopback capture pipeline connected to the playback pipe. We don't want to pass playback stream params to the capture pipeline, because directions are different. Now let's take mixer topology. We want to pass params to the mixer pipeline, because otherwise it will stay unconfigured. I know that we could probably insert additional logic into these components, but for me it doesn't look flexible enough.

[lgirdwood]

@tlauda

1. playback loopback PCM to capture PCM example is first user sets the pipe params. i.e. if capture params come first then they are immutable in the pipeline until capture is closed. i.e. params can be locked based on pipe usage count.
2. mixer does not change any params. Rules are same as 1. If two PCMs are connected to a mixer, then params are immutable after the first PCM has configured them. The second PCM has to use the same params (unless there is a conversion component) otherwise it params will fail.

The key thing here is to keep a set of simple and consistent rules that can be easily applied to any use case and provide immediate feedback to userspace. I'm going to review the pipeline rules next week, I want to avoid adding numerous rules that apply to only certain components. I will detail them in a PR.

[juimonen]

@tlauda I might be understanding it wrong, but as I see it, the propagation of parameters to connected pipelines is not our problem. Problem is when to schedule those pipelines. Now with mixer we have "overlapping" scheduling, so depending on pcm we might need to schedule whole pipeline or parts of 2 pipelines. Now despite how we define or chop our pipelines, someone still needs to decide which parts or which pipelines to run?

[tlauda]

@juimonen Currently scheduling is the least of our worries. Current logic will work correctly as long as there won't be any complicated cases. Mixer pipeline will be the one driving the scheduling of connected host pipelines, so it should be started along with the first started connected host stream. The problem is who should decide when to run mixer pipeline:

1. Host by explicitly sending ipc along with the first host ppl (granted that it will be separated from host ppl).
2. Host by explicitly sending ipc right after creation (granted that mixer will be producing zeroes if no source is connected).
3. FW by propagating trigger start when first host ppl is started (current implementation).

[lgirdwood]

@tlauda @juimonen host will not directly schedule pipelines, but will indirectly schedule via

1. PCM device trigger()
2. kcontrol based trigger().