Add support for hostless and DAIless pipelines #5609

ranj063 · 2025-12-02T01:54:40Z

No description provided.

sound/soc/intel/boards/sof_sdw.c

singalsu · 2025-12-02T09:15:54Z

I tested this PR with other echo ref capture related PRs (thesofproject/sof#10329 and thesofproject/sof#10387), it works perfectly.

lgirdwood

Some minor opens

lgirdwood · 2025-12-04T15:49:33Z

sound/soc/intel/boards/sof_sdw.c

+{
+	struct device *dev = card->dev;
+	int ret;
+	char *name = devm_kasprintf(dev, GFP_KERNEL, "EchoRef_virtual_DAI");


Will this always be echo ref or can it also be a capture device for recording playback ?

This is set up as as capture device for recording playback by default f playback is active. If playback is not active, it produces silence

ok, so could we make a more generic/meaningful name so that users will know what to do with it.

This looks too fragile to me.
It just happens that we use a tone/signal generator (which generates 0) to feed to an EchoRef capture PCM, but the concept is defined in topology.

Do you have topology PR to see how this looks like?

Here you go @ujfalusi. This is what an echo ref topology looks like

ok, so could we make a more generic/meaningful name so that users will know what to do with it.

@lgirdwood how about "LoopbackCapture_virtual_DAI"?

sound/soc/sof/ipc4-topology.h

sound/soc/sof/ipc4-topology.c

sound/soc/sof/sof-audio.c

lgirdwood · 2025-12-04T16:03:51Z

sound/soc/sof/sof-audio.c

 		goto sink_prepare;

+	/* skip aggregated DAIs */
+	if(is_aggregated_dai(swidget))


sound/soc/sof/sof-audio.c

ujfalusi

@ranj063, I don't think I understand all the details and how this changes the whole walking logic, I trust that the logic is solid.

The last patch revealed (to commit message) how the direction comes to be used...

I suppose it could be possible to add a simple tone generator now:
virtual DAI -> tone generator -> Host (tone capture)
but it is not, isn't it? We would need to change the machine driver and other things to match with the topology change?

I'm not sure if there is a more dynamic, topology driven way to achieve the virtual DAI concept, which would give really nice user feature at the end.

ujfalusi · 2025-12-08T11:19:31Z

sound/soc/intel/boards/sof_sdw.c

+{
+	struct device *dev = card->dev;
+	int ret;
+	char *name = devm_kasprintf(dev, GFP_KERNEL, "EchoRef_virtual_DAI");


This looks too fragile to me.
It just happens that we use a tone/signal generator (which generates 0) to feed to an EchoRef capture PCM, but the concept is defined in topology.

Do you have topology PR to see how this looks like?

ujfalusi · 2025-12-08T11:20:58Z

sound/soc/intel/boards/sof_sdw.c

+	ret = asoc_sdw_init_simple_dai_link(dev, *dai_links, be_id, name,
+					    0, 1, "snd-soc-dummy-dai", "dummy",
+					    snd_soc_dummy_dlc.name, snd_soc_dummy_dlc.dai_name,
+					    1, NULL, NULL);


Only sdw can have this feature, HDA or SSP machines never?
We cannot add to topology a tone generator for example at will, but we need to change the kernel as well?

In theory the same logic would work for all machines and yes you would need the machine driver change in order to use it. But in the case of SSP, we dont need this. We can use the Loopback mode like we've always used. So maybe just the HDA machine change would be enough

HDA and SSP not priority.

include/uapi/sound/sof/tokens.h

ujfalusi · 2025-12-08T11:26:37Z

sound/soc/sof/ipc4-topology.c

+			out_fmt = &available_fmt->output_pin_fmts[0].audio_fmt;
+
+			/* copy output format */
+			memcpy(&process->base_config.audio_fmt, out_fmt, sizeof(*out_fmt));


what will happen if the fe_parmas and the first output_fmt of the module does not match?

You'll end up with an error that out format match wasnt found on line 2802 isnt it?

sound/soc/sof/ipc4-topology.c

ujfalusi · 2025-12-08T11:38:30Z

sound/soc/sof/sof-audio.c

 #include "sof-audio.h"
 #include "ops.h"

+/*


How does one 'start' such a tone generator playback? There is no PCM device involved, so there must be a kcontrol switch which forces the system to motion.
How?

There is a PCM with the tone generator pipeline. It serves the purpose of propragating the hw_params and triggers to the list of connected DAPM widgets. A kcontrol is a possibility but without a PCM, it wont be easy to know which widgets to set up or even how to the hw_params for the FE DAI and BE DAI and the codec. The PCM is a shortcut in this case to achieve that functionality

ujfalusi · 2025-12-08T11:41:46Z

sound/soc/sof/sof-audio.c

+{
+	return (WIDGET_IS_DAI(swidget->id) &&
+	        isdigit(swidget->widget->name[strlen(swidget->widget->name) - 1]) &&
+	        swidget->widget->name[strlen(swidget->widget->name) - 1] != '0');


how did this worked then currently if we should not be dealing with the .[1..9] DAIs?

today it works because we stop traversing the path when we see a virtual widget. So if you look at the aggregated DAI alh-copier-SDW1.Playback.1 in the topology I shared in another comment, it is preceded by a virtual widget. So we see that and ignore everything below it. But now for tone and echo ref we want to go down the path from either an aggregated DAI or a virtual widget to the sink components in the path.

sound/soc/sof/sof-audio.c

ranj063 · 2025-12-10T00:12:40Z

I suppose it could be possible to add a simple tone generator now:
virtual DAI -> tone generator -> Host (tone capture)
but it is not, isn't it? We would need to change the machine driver and other things to match with the topology change?

@ujfalusi yes this is all you need in topology and it will work. No need to change anything for tone playback.

Align with the firmware and add the missing token for pipeline kcps. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

singalsu

This patch version worked OK with firmware and topology patches to create echo reference capture PCMs.

sound/soc/sof/sof-audio.c

ranj063 · 2025-12-19T07:24:35Z

dropped support for hostless playback for now> will be added later

singalsu · 2025-12-19T08:40:02Z

dropped support for hostless playback for now> will be added later

@ujfalusi @ranj063 I just tested this latest PR version, it works well.

ujfalusi

@ranj063, I have few comments and I still need to rely on your word that the changes in walking are ok (and @singalsu's testing).

Now that the tone_generator -> ... -> playback DAI is removed, this looks much cleaner and better rounded.

sound/soc/sof/pcm.c

ujfalusi · 2025-12-19T09:07:14Z

sound/soc/intel/boards/sof_sdw.c

+	if (ret)
+		return ret;
+
+	(*dai_links)++;


how this will work with existing topologies and with function topology?

It shouldnt matter if we use function topologies right? We just have a single machine even in that case right?

I think the function topology parsing will fall back to monolithic when it faces with a link of unknown origin/no fragment.
We have now patch to make this not fail when there is no monolithic topology defined, but this (I think) will eventually disable the function topologies?

I'm not sure, but this is my feeling.

best to comment what the assumption will be here regarding topology.

ujfalusi · 2025-12-19T09:09:28Z

sound/soc/intel/boards/sof_sdw.c

-	/* allocate BE dailinks */
-	num_links = sdw_be_num + ssp_num + dmic_num + hdmi_num + bt_num;
+	/* allocate BE dailinks, add an extra DAI link for echo reference capture */
+	num_links = sdw_be_num + ssp_num + dmic_num + hdmi_num + bt_num + 1;


I guess this is also a chicken and egg problem... This is purely topology construct, but we don't know if the topology have virtual DAI before we pick and parse the topology and for that we need the links in place if the topology do have this defined, right?

ok, lets capture this behavior in the comments.

ujfalusi · 2025-12-19T09:25:23Z

sound/soc/sof/ipc4-topology.h

 	struct sof_ipc4_msg msg;
 	bool skip_during_fe_trigger;
+	bool direction_valid;
+	u32 direction;


should it be documented what values are valid for direction, like what 0 means, what 1 means, is there a direction == 2...10?

@ujfalusi these come directly from topology, so are checked for validity there.

so, the value for kernel does not matter, only they should match?

we can add that context to the comment. Can complain too if out of range.

ujfalusi · 2025-12-19T12:13:54Z

sound/soc/sof/ipc4-topology.c

+				SOF_IPC4_AUDIO_FORMAT_CFG_CHANNELS_COUNT(in_fmt->fmt_cfg);
+			out_ref_valid_bits =
+				SOF_IPC4_AUDIO_FORMAT_CFG_V_BIT_DEPTH(in_fmt->fmt_cfg);
+			out_ref_type = sof_ipc4_fmt_cfg_to_type(in_fmt->fmt_cfg);


and to add I have this PR for some time which touches the same code and fixes issue when not all parameters are changed by a process module:
#5442

sound/soc/sof/sof-audio.c

lgirdwood

LGTM, on my side it may benefit from more comments where expectations/behaviours are unclear.

lgirdwood · 2025-12-19T14:11:00Z

sound/soc/intel/boards/sof_sdw.c

+	ret = asoc_sdw_init_simple_dai_link(dev, *dai_links, be_id, name,
+					    0, 1, "snd-soc-dummy-dai", "dummy",
+					    snd_soc_dummy_dlc.name, snd_soc_dummy_dlc.dai_name,
+					    1, NULL, NULL);


HDA and SSP not priority.

lgirdwood · 2025-12-19T14:16:20Z

sound/soc/intel/boards/sof_sdw.c

+	if (ret)
+		return ret;
+
+	(*dai_links)++;


best to comment what the assumption will be here regarding topology.

lgirdwood · 2025-12-19T14:17:17Z

sound/soc/intel/boards/sof_sdw.c

-	/* allocate BE dailinks */
-	num_links = sdw_be_num + ssp_num + dmic_num + hdmi_num + bt_num;
+	/* allocate BE dailinks, add an extra DAI link for echo reference capture */
+	num_links = sdw_be_num + ssp_num + dmic_num + hdmi_num + bt_num + 1;


ok, lets capture this behavior in the comments.

sound/soc/intel/boards/sof_sdw.c

lgirdwood · 2025-12-19T14:20:03Z

sound/soc/sof/ipc4-topology.h

 	struct sof_ipc4_msg msg;
 	bool skip_during_fe_trigger;
+	bool direction_valid;
+	u32 direction;


we can add that context to the comment. Can complain too if out of range.

sound/soc/sof/ipc4-topology.c

Add a DAI link for loopback capture as the last link to make sure the other DAI link ID's remain unaffected. It serves as a dummy DAI link to enable echo reference capture in the SDW topologies which do not have an actual backend capture DAI. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

Parse the pipeline direction from topology. The direction_valid token is required for backward-compatibility with older topologies that may not have the direction set for pipelines. This will be used when setting up pipelines to check if a pipeline is in the same direction as the requested params and skip those in the opposite direction like in the case of echo reference capture pipelines during playback. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

…ut pins A tone generator module can be a type of processing module with no input pins. Adjust the logic to set the reference params for selecting output format and the basecfg format based on the output format. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

Aggregated DAI widgets exist in topology for representation and are not actually initialized in the firmware. But in preparation for using this as a virtual DAI for loopback capture, make sure that we can traverse the path from an aggregated DAI widget to the host widget. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

An example of a DAI-less loopback pipeline would be the echo reference capture in the speaker playback path. This pipeline is set up as follows: Host(Playback) -> mixin -> mixout -> gain -> module-copier -> DAI | V Host(Capture) <- Process module <- virtual DAI In the above example, the virtual DAI exploits the concept of an aggregated DAI (one with a non-zero DAI ID) in topology to enable this pipeline to work with DPCM. A virtual DAI is a DAI widget with a non-zero DAI ID and hence is skipped when traversing the list of DAPM widgets during widget prepare/set/up/free/unprepare. The process module in the above pipeline generates 0's that are captured by the echo reference PCM. When the playback path is active, the process module acts as a passthrough module to allow the playback samples to be passthrough to the capture host. In order for these pipelines to work properly, the logic for setting/preparing/freeing/unpreparing the widgets needs to be amended to make sure that only the widgets that are in the pipeline in the same direction as the PCM being started are set up. For example, when the playback PCM is started, the capture pipeline widgets also show up in the list of connected DAPM widgets but they shouldn't be set up yet because the echo reference capture PCM hasn't been started yet. Alternatively, when the echo reference capture PCM is started, the playback pipeline widgets should not be setup. Finally, the last step needed to put this all together is the set the routes for widgets connecting the playback and the capture pipelines when both are active. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

ranj063 · 2025-12-19T17:07:54Z

SOFCI TEST

ranj063 · 2025-12-20T02:16:47Z

SOFCI TEST

ranj063 requested review from bardliao, dbaluta, kv2019i, lgirdwood, lyakh, plbossart and ujfalusi as code owners December 2, 2025 01:54

ranj063 mentioned this pull request Dec 2, 2025

Add support for hostless pipelines #5571

Closed

bardliao reviewed Dec 2, 2025

View reviewed changes

sound/soc/intel/boards/sof_sdw.c Show resolved Hide resolved

bardliao reviewed Dec 2, 2025

View reviewed changes

sound/soc/intel/boards/sof_sdw.c Outdated Show resolved Hide resolved

ranj063 force-pushed the fix/echo_ref_new branch 2 times, most recently from 44a47e3 to 6c97700 Compare December 2, 2025 19:48

bardliao previously approved these changes Dec 3, 2025

View reviewed changes

ranj063 dismissed bardliao’s stale review via 640894b December 3, 2025 16:40

ranj063 force-pushed the fix/echo_ref_new branch from 6c97700 to 640894b Compare December 3, 2025 16:40

lgirdwood reviewed Dec 4, 2025

View reviewed changes

ujfalusi reviewed Dec 8, 2025

View reviewed changes

ranj063 force-pushed the fix/echo_ref_new branch from 640894b to ebdfe34 Compare December 10, 2025 02:01

ranj063 requested review from bardliao, lgirdwood and ujfalusi December 10, 2025 02:01

uapi: sound: sof: tokens: Add missing token for KCPS

216feda

Align with the firmware and add the missing token for pipeline kcps. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

ranj063 force-pushed the fix/echo_ref_new branch from ebdfe34 to 43616af Compare December 10, 2025 16:12

singalsu mentioned this pull request Dec 10, 2025

Tools: Topology: Add echo reference for SDW speaker and jack thesofproject/sof#10387

Merged

singalsu approved these changes Dec 10, 2025

View reviewed changes

sound/soc/sof/sof-audio.c Outdated Show resolved Hide resolved

ranj063 force-pushed the fix/echo_ref_new branch from 43616af to 779773c Compare December 10, 2025 17:19

ranj063 force-pushed the fix/echo_ref_new branch from 779773c to 57524a2 Compare December 19, 2025 07:21

bardliao previously approved these changes Dec 19, 2025

View reviewed changes

ujfalusi reviewed Dec 19, 2025

View reviewed changes

ranj063 dismissed bardliao’s stale review via 2b625b2 December 19, 2025 13:57

ranj063 force-pushed the fix/echo_ref_new branch from 57524a2 to 2b625b2 Compare December 19, 2025 13:57

ujfalusi previously approved these changes Dec 19, 2025

View reviewed changes

ranj063 dismissed ujfalusi’s stale review via 3e91b71 December 19, 2025 14:26

ranj063 force-pushed the fix/echo_ref_new branch from 2b625b2 to 3e91b71 Compare December 19, 2025 14:26

lgirdwood reviewed Dec 19, 2025

View reviewed changes

ranj063 added 5 commits December 19, 2025 06:33

ranj063 force-pushed the fix/echo_ref_new branch from 3e91b71 to ab6ff22 Compare December 19, 2025 14:34

lgirdwood approved these changes Dec 19, 2025

View reviewed changes

ujfalusi approved these changes Dec 19, 2025

View reviewed changes

bardliao approved these changes Dec 22, 2025

View reviewed changes

bardliao merged commit f2701ee into thesofproject:topic/sof-dev Dec 22, 2025
11 of 16 checks passed

Add support for hostless and DAIless pipelines #5609

Add support for hostless and DAIless pipelines #5609

Uh oh!

Conversation

ranj063 commented Dec 2, 2025

Uh oh!

Uh oh!

Uh oh!

singalsu commented Dec 2, 2025

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ujfalusi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ranj063 commented Dec 10, 2025

Uh oh!

singalsu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ranj063 commented Dec 19, 2025

Uh oh!

singalsu commented Dec 19, 2025

Uh oh!

ujfalusi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!