sof-hda-dsp: HDMI: IPC3: no multichannel support

[perexg]

We have a bug report in pipewire that https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4755 about missing multichannel PCM support when sof-hda-dsp driver is used. Multichannel HDMI output works with the legacy HDA driver.

Please, consider to add support for the multichannel output to HDMI PCM in SOF HDA driver.

[ujfalusi]

@perexg, with IPC4 we do support multichannel and bytestream (DTS, DD, AC3, etc) passthrough via HDMI.
ucm will create the the needed PCM aliases for this in case of HDA or SoundWire setup:
alsa-project/alsa-ucm-conf@a4115e8
alsa-project/alsa-ucm-conf@2740b6c

Since this needs IPC4, it means that it works on MTL or newer platforms (while TGL/ADL can be forced to use IPC4 we might be missing the needed topology as they are primarily IPC3 platforms).

PRL is also IPC3 but generic HDA should work on them in IPC4, however we only have a single SDW topology for this platform compared to 12 for IPC3... (options snd_sof ipc_type=1 (or snd_sof_pci on older kernels, but IPC4 is officially not supported on cAVS2.5 platforms)

[perexg]

@ujfalusi : It seems that hardware is Lenovo ThinkPad Yoga L13 Gen 4 - there should be 13th generation CPU (Raptor Lake). So the HDMI multichannel is not supported on this platform? The driver advertise only stereo (two channels): https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4755#note_2962128 .

Asked affected user to provide alsa-info.sh output.

[ujfalusi]

@perexg, yes, IPC3 only advertises stereo. With IPC3 we don't have support for "ChainDMA" and this is needed for the passthrough to work - in this mode the firmware is just passes the data as it is from ALSA buffer to the HDA codec while non ChainDMA PCMs do light processing.

With ChainDMA the HDMI PCM devices work in a similar way as with legacy HDA, but the HD-DMA host and link side are decoupled.

[perexg]

So my understanding is:

• the older platforms support only stereo for HDMI devices
• it's not caused by hardware limits, but the limit is applied with older (IPC3 vs IPC4) firmware/topology version

Not sure, how to explain this limit to users now. So the request to add support for older platforms seems valid.

[ujfalusi]

@perexg, IPC3 is in maintenance mode for Intel platforms, but we have limited and experimental IPC4 support for cAVS2.5 platforms (tgl/adl/rpl). It can be enabled by options snd_sof ipc_type=1 and if the topology is available then it will work. The main limitation of IPC4 on older platforms are the lack of topology files and we cannot commit to switch cAVS2.5 to IPC4 for users as it likely going to cause regression.

[ujfalusi]

@perexg, the other option is to switch to legacy HDA mode (options snd_intel_dspcfg dsp_driver=1) if the DMIC is not needed (the laptop is used as entertainment PC only).

[perexg]

I already suggested this solution, but the user does not expect to lose the mic support - see the pipewire report.

[ford-prefect]

Is the IPC4 option (options snd_sof ipc_type=1) something we can/should recommend to users as workaround they can try? I assume limited + experimental means that there might be issues later even if it does seem to work?

[lgirdwood]

Is the IPC4 option (options snd_sof ipc_type=1) something we can/should recommend to users as workaround they can try? I assume limited + experimental means that there might be issues later even if it does seem to work?

Ack - this would be a WA for issue (@ujfalusi pls confirm if any other kernel options needed). IPC4 does get validation on some older platforms so things "should work" but are not officially supported by Intel. As @ujfalusi said, the IPC4 FW maybe missing a topology for the users HW - however topology is something users can modify, recompile and test using standard ALSA tools.

[ujfalusi]

If the topology is available then options snd_sof ipc_type=1 (or options snd_sof_pci ipc_type=1 on older kernels) is the only thing that would be needed.
One can set this option and observe the kernel boot log to confirm that the IPC4 is indeed in use - the kernel will fall back to IPC3 if firmware (unlikely) or topology is missing, but it will note this in info level.
As @lgirdwood noted, missing topology files can be created (patches welcome) based on existing ones relatively easily.

[Interpolated-Watermelon]

Hi all - I'm the 'affected user' here, although I didn't submit the original issue on pipewire, so I suspect there are others.

Thanks for having a look at this and apologies for my joining this late - to be honest, I wasn't sure how I could add anything of use. I've spent two evenings now trying to read through and understand the above discussion, but I have to admit it's largely completely incomprehensible. Every new term or acronym I google just leads to another wiki full of language totally alien to me.

@perexg kindly clarified in the pipewire issue where to put options snd_sof ipc_type=1 / options snd_sof_pci ipc_type=1 ( in a file called /etc/modprobe.d/dsp.conf, where I used to have options snd-intel-dspcfg dsp_driver=1) but this sadly hasn't worked. I'm not sure how to get the specific 'kernel boot log' mentioned above, is that journalctl -b? Happy to provide if someone can clarify.

On a broader note - I see in a few places that my hardware (a Lenovo ThinkPad Yoga L13 Gen 4 as @perexg correctly stated) seems to be referred to as an 'older platform'. This is very confusing to me. We purchased these as ex-educator models only about a month ago, through a program with my wifes' work, as they turn over staff laptops yearly. They actually still have over two years of factory warranty on them. Perhaps I've misunderstood - again, the technical language here is quite inscrutable - but it seems odd that this issue is being blamed on the age of a unit still up for sale on Lenovo's website as I write this. It's odder still, considering that it's also on Lenovo's official Linux-supported laptops list: https://support.lenovo.com/us/en/solutions/pd031426-linux-for-personal-systems.

Based on this, and the advice of her friend in their IT dept, we wre under the impression that these were contemporary machines that would have years of firmware updates and be ideal for a novice/casual user looking to try linux full time as an alternative to the frustratin direction Win11 has gone. Odder still - I actually borrowed a Gen 2 L13 so she could trial Fedora before committing, and HDMI surround was something we specifically tested as it's a 'must' for her. So again, I don't quite understand why the Gen 4 can only support stereo as an "older platform", when the 2 year older Gen 2 supports it just fine?

Moreover, does this mean ALL 13th gen intel laptops have the same limitation under Linux?? I see a "Raptor Lake P/U/H cAVS" suffix in the GNOME output options, so now I'm worried that whatever else I purchase will have the same issue unless I get something....newer? Because a 2023 laptop is too 'old'? But a 2021 L13 G2...isn't? On the whole, I'm just really confused.

@ujfalusi I'm quite happy to try and make one of these 'topology files', if someone can give some layperson-friendly instruction. I've spent most of this evening browsing through alsa-project.org/wiki/ trying to find something relatable but again - it's all seems to be written expressly for people who already know what it is and what they're doing.

Equally, I'd settle for anything that lets us 'switch' between the normal situation (with a working mic - a must for us both) and options snd-intel-dspcfg dsp_driver=1 to enable HMDI 5.1 without reboot (a must for my wife).

Otherwise realistically we're going to have to take a financial hit and replace at least one of these with....I dont even know what.

Thanks again for all your time.

PS I've attached the alsa-info output requested:

alsa-info.txt

[ujfalusi]

@Interpolated-Watermelon, when we talk about generations we talk about generations of the DSP, Tiger Lake/Alder Lake/Raptor Lake have cAVS2.5 (old generation) Meteor Lake family has ACE1, Lunar Lake ACE2.
IPC3 was developed on cAVS version up to 2.5 and IPC4 is for newer, ACE audio subsystems but we have experimental support for cAVS2.5.
Some audio peripheral needs DSP to function, like DMIC, SSP and SoundWire. If you have any of these in the system you must use the DSP and for that you need SOF, the firmware and the topology.
If you only have HDA audio then SOF is not needed, the legacy driver stack will be used which bypasses the DSP, it is a win-loose situation as you use the bare metal audio, but you loose the additional functionality the firmware can give (in audio processing, refinement, etc).
IPC3 had/has a feature set which does not include things like HDMI multichannel or passthrough, it is a mature solution used by millions of Chromebooks (all Intel based chromebook released in the past decade uses SOF).

As a twist: higher end laptops tend to have DMIC arrays for better conferencing and thus they need the DSP to be used, if it is cAVS platform then it is defaulting to IPC3, thus you tread-off the DMIC for HDMI multichannel.

It is indeed confusing, but we try to be clear on these gains and limitations. Our aim is to provide the best audio experience as possible given the limitations.

[ujfalusi]

@Interpolated-Watermelon, the alsa-info output looks promising, it looks like that IPC4 is in use:

Card sysdefault:0 'sofhdadsp'/'LENOVO-21FKS01C00-ThinkPadL13YogaGen4'
  Mixer name	: 'Realtek ALC257'
  Components	: 'HDA:8086281f,80860101,00100000 HDA:10ec0257,17aa50c9,00100001 cfg-dmics:2 iec61937-pcm:5,4,3'
  Controls      : 50
  Simple ctrls  : 17

iec61937-pcm:5,4,3 indicates this w/o seeing the kernel log. ALSA packages are new (1.2.14-2), so that is also good.

There are couple of things to check on the lower level.
what is the output of aplay -L - the list of PCMs?
if the list does not include:

hdmi:CARD=sofhdadsp,DEV=0
    sof-hda-dsp, 
    HDMI Audio Output
hdmi:CARD=sofhdadsp,DEV=1
    sof-hda-dsp, 
    HDMI Audio Output
hdmi:CARD=sofhdadsp,DEV=2
    sof-hda-dsp, 
    HDMI Audio Output

then can you check if /var/lib/alsa/card0.conf.d exists and it contains 42-sof-hdmi.conf file?
If not, then:

sudo mkdir -p /var/lib/alsa/card0.conf.d
sudo alsactl init # not sure if it needs to be root...

then check again /var/lib/alsa/card0.conf.d and if the sof-hdmi.conf is there, see the aplay -L as well.
Probably you need to reboot for GNOME, but not sure.

These hdmi: PCMs are needed for multichannel audio afaik.

You can test of multichannel work (again in lower level):
speaker-test -Dhdmi:CARD=sofhdadsp,DEV=0 -c6 -W /usr/share/sounds/alsa/ -t wav
mplayer -ao alsa:device=hdmi=sofhdadsp,DEV=0 -ac hwac3,hwdts <path to video
mpv --audio-device=alsa/hdmi:CARD=sofhdadsp,DEV=0 --audio-spdif=ac3,eac3,dts-hd,truehd

If things works in this low level then I'm not sure why GNOME is not giving you the multichannel option.