On 2/7/22 07:25, Cezary Rojewski wrote:
> Shape of a stream on DSP side, that is, the number and the layout of
> its pipelines and modules is paramount for streaming to be efficient and
> low power-consuming. Add parsing helpers to support loading such
> information from the topology file.
again what is a 'stream'?
> +struct avs_tplg_path {
> + u32 id;
> +};
A concept that boils down to a single integer is really far from clear
to me. What does this represent really?
> +
> +struct avs_tplg_pipeline {
> + u32 id;
> +
> + struct avs_tplg_pplcfg *cfg;
> + struct avs_tplg_binding **bindings;
> + u32 num_bindings;
> + struct list_head mod_list;
> +
> + struct avs_tplg_path *owner;
the cardinality between path and pipeline is far from clear. When you
have topologies where the same data can be rendered on multiple outputs
and demuxed into an echo reference, then what is the 'path'?
Worst case all connected pipelines could be a single path with this
hierarchical definition of ownership, but is this desired?
What happens when the user uses switches to disconnects pipelines?
> + /* Path pipelines management. */
what is a path pipeline?
> + struct list_head node;
> +};
> +
> +struct avs_tplg_module {
> + u32 id;
what is the definition of id? is this local to the scope of a pipeline?
global for the entire topology?
> +
> + struct avs_tplg_modcfg_base *cfg_base;
> + struct avs_audio_format *in_fmt;
> + u8 core_id;
> + u8 domain;
> + struct avs_tplg_modcfg_ext *cfg_ext;
> +
> + struct avs_tplg_pipeline *owner;
> + /* Pipeline modules management. */
> + struct list_head node;
> +};
I would expect all modules to be seen as DAPM widgets, no?
> +
> #endif
