[kv2019i]

The ALH DAI class defines "direction" as a string attribute with token_ref "dai.word", but lacks the tuple_values mapping that other classes (dai, dai-copier, host-copier) use. As a result the string values "playback"/"capture" end up verbatim in a word tuple.

Older alsa-lib converted such strings with strtoul() and silently encoded them as 0 (so capture links were also encoded as 0). Since alsa-lib commit c41be26af2d9 ("topology: use snd_config_get_llong() in tplg_get_integer/unsigned()"), non-numeric strings are rejected and the build of e.g. cavs-sdw.tplg fails with:

ALSA lib data.c:866:(parse_tuple_set) [error.topology] tuple direction: Invalid argument

Add tuple_values to map the direction strings to numeric values.

Link: alsa-project/alsa-lib@c41be26

[kv2019i]

This fixes SOF build with upstream alsa-lib. @ujfalusi and @bardliao I do wonder should we alternatively drop the direction value for ALH. Based on my analysis, it is not really used by the kernel, which explains why the wrong values in existing topologies have not caused any bad outcomes. My checks so far from kernel source:

• IPC4: never reads this token. Its dai_tokens list (ipc4-topology.c:150) has only SOF_TKN_DAI_TYPE and SOF_TKN_DAI_INDEX.
• IPC3: reads it in one place, the dai_tokens entry at ipc3-topology.c:88, which fills sof_ipc_comp_dai.direction. That list is applied only to DAI widget tuples (swidget->tuples, ipc3-topology.c:1630).
• Link private data: sof_link_load() (topology.c:2028-2050) copies only the SOF_DAI_LINK_TOKENS set (type and index, no direction) plus the per-DAI-type set. For ALH, those are just the ALH rate and channels tokens. Tuples are matched by token ID, so a direction tuple in link data is skipped.

So as an alternative to this PR, we could also drop "dai.word" from ALH. Let me know what you think.

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

No open issues 🎉

What changed in this PR

Adds an explicit tuple_values mapping for the ALH DAI direction attribute so string tokens (playback/capture/duplex) are encoded as numeric tuple values and don’t fail parsing on newer alsa-lib.

Changes:

• Add !tuple_values for ALH direction to map direction strings to numeric values (0/1/2).

File	Description
tools/​topology/​topology2/​include/​dais/​alh.conf	Adds tuple_values mapping for direction to ensure topology tuple encoding works with stricter alsa-lib parsing

_{Review effort: Lite}

[intel-sofci]

PR 11412: test results

Run date: 2026-11-09 11:56 UTC

Tested commit: 4bbf0eb5b244d2cecefa9ca11d94895a53b287fc

[bardliao]

@kv2019i It looks all DAI have the direction attribute. I will not suggest removing it. Can we remove token_ref "dai.word" and treat it as a String?

[kv2019i]

@bardliao wrote:

@kv2019i It looks all DAI have the direction attribute. I will not suggest removing it. Can we remove token_ref "dai.word" and treat it as a String?

Ok, this is better idea. Seems this is safe w.r.t. old kernels, decoded binaries benefit from extra readability and SOF can be built with upstream alsa-lib (again).

V2 pushed.

[kv2019i]

V3:

• no change, repushed as the github checks were stuck and not run

[kv2019i]

Topologies not tested by the one CI Intel check that is still pending (and seems to be stuck). Bypassing and proceeding with merge.