Fixed in latest push.
Updated XCHAL_CORE_ID in core-isa.h to "ACP73x_HiFi5_NNE_PROD" to match XTENSA_CORE. The core-isa.h value was incorrect, not the build script.

Can you @singalsu check this? This is first time we have HW dependencies the the PCM converter list.

It would prefer if we could keep same interpretations of the sample formats. This patch suggest your hardware natively 24bit encoding where the audio samples are stored in the 3 most significant bytes. The format we use for this is SOF_IPC_FRAME_S24_4LE_MSB.

So in theory, you'd set the correct format in either DSP topology, or some of the HW specific code. E.g. for Intel, we overrode the sample format in sof/src/ipc/ipc3/dai.c:ipc_dai_data_config().

Then we could keep the converter table vendor neutral.

Thanks for the review.
The ACP 7.X hardware DMA strips the LSB byte from the 32-bit container and transmits only the upper 3 bytes to the bus. So 24-bit samples need to be MSB-aligned (left-shifted by 8) in the 32-bit word before reaching the DMA — which is exactly what pcm_convert_s32_to_s24_be does.
The reason we handle this at the converter level rather than changing the format enum:
PipeWire/ALSA negotiates S24_LE or S32_LE and sends LSB-aligned data (S24_4LE). The host-side format negotiation expects this standard format.
The MSB alignment is a hardware-level requirement specific to how the ACP DMA feeds data to the bus, rather than a format property of the audio pipeline. The converter is the appropriate place to handle this.
Overriding the format in ipc_dai_data_config() would only change the format label without performing the actual bit-shift — the incoming data from the host is still LSB-aligned S24_4LE, so a real conversion step is still needed before the data reaches the DMA.
The #if defined(CONFIG_SOC_ACP_7_X) guard keeps this hardware-specific conversion isolated so it doesn't affect other platforms at all.

There are two negotiations here, the host side (what ALSA sends to/from SOF/DSP) and DAI side (what SOF/DSP sends to/from audio interfaces). So how this should work (playback example):

• ALSA can send e.g. S24_LE to DSP (no change)
• DSP pipe can use intermediate format based on what modules support (either process S24_LE natively or convert to their own intermediate format, this is configured in DSP topology)
• at DSP output, another negotiation happens and if only a fixed format (e.g. S24_4LE), PCM converter will be setup to convert to the hw supported format

We already do this for some Intel hw audio interfaces and this has worked without having special cases in the PCM converter, so I'd expect same to work in your case for ACP.

Thank you @kv2019i for your response.
We had already investigated this approach earlier. The S24_4LE_MSB converter entries only exist in the IPC4 pcm_func_vc_map[] table (4-column lookup). The IPC3 pcm_func_map[] table (2-column, used by pcm_get_conversion_function()) has no S24_4LE_MSB entries. So we tried adding new generic S32_LE ↔ S24_4LE_MSB entries to the IPC3 converter table along with the format override in ipc_dai_data_config() — that approach also builds and works.

However, we kept it under CONFIG_SOC_ACP_7_X in the existing converter table to avoid adding new entries that could potentially impact other platforms. If you'd prefer the generic IPC3 table entries approach instead, we already have that ready and build-tested. Please let us know which you'd prefer.

Thanks for the review.
The ACP 7.X hardware DMA strips the LSB byte from the 32-bit container and transmits only the upper 3 bytes to the bus. So 24-bit samples need to be MSB-aligned (left-shifted by 8) in the 32-bit word before reaching the DMA — which is exactly what pcm_convert_s32_to_s24_be does.
The reason we handle this at the converter level rather than changing the format enum:
PipeWire/ALSA negotiates S24_LE or S32_LE and sends LSB-aligned data (S24_4LE). The host-side format negotiation expects this standard format.
The MSB alignment is a hardware-level requirement specific to how the ACP DMA feeds data to the bus, rather than a format property of the audio pipeline. The converter is the appropriate place to handle this.
Overriding the format in ipc_dai_data_config() would only change the format label without performing the actual bit-shift — the incoming data from the host is still LSB-aligned S24_4LE, so a real conversion step is still needed before the data reaches the DMA.
The #if defined(CONFIG_SOC_ACP_7_X) guard keeps this hardware-specific conversion isolated so it doesn't affect other platforms at all.