ucm2: sof: hdmi: Add 5.1 and 7.1 variants of HDMI devices when using IPC4

[ujfalusi]

Systems using IPC4 can support up to 8 channels of audio (and passthrough) via HDMI.

In UCM the default PlaybackChannels is set to 2, which prevents users from selecting multichannel configurations.

When probing the card, Pipewire will drop configurations that are not supported either by the PCM device or based on ELD information.
This means that if the equipment supports only stereo then the 5.1 and 7.1 variants should not be visible, if the equipment is 5.1 capable, then only the 7.1 variant is removed.

The kernel will refine the PCM parameters based on the ELD information as wall when https://lore.kernel.org/linux-sound/[email protected]/ is applied.

@perexg, @wtay, @ford-prefect, is this something which can help PW and user space to handle the HDMI a bit better with SOF?

[perexg]

pipewire issue and discussion: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4755#note_3171336

In UCM the default PlaybackChannels is set to 2, which prevents users from selecting multichannel configurations.

A little correction: UCM does not set PlaybackChannels for HDMI devices (but it's assumed that the number is 2 by default when this variable is missing).

[ujfalusi]

@perexg, I think this is not a workable solution, it results too confusing UI for end users.
KDE's profile selection:

[perexg]

To compare with the "legacy" ACP driver which combines only HDMI and analog I/O (sorry, some names are in Czech, but it does not matter for this example):

I think that we should move this discussion to https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4755 , because it's mostly about to put a lot of variants to one dimensional array.

[ujfalusi]

@perexg, I guess this is also boils down on how PW/WP interprets legacy HDA and UCM (SOF HDA or SNDW for example)
Legacy HDA have profiles and ports, UCM have only profiles but no ports
Legacy:

UCM/sof-hda:

In Legacy you select Analog Duplex as profile and then you can select Speaker/Headphone for the Playback port, and also select the port for capture. Basically you have a single Playback/Capture device per ALSA card (?), hence when you want to use HDMI, the speaker is on a different profile

With UCM card you select the profile and that might or might give you a list of different devices that you can select from it kind of provides the same information, but in a different way, right?
The profiles contain certain mix of devices based on permutation, but there is no profile with Speaker and Headphone for example, this makes switching from speaker to headset on insert and back to speaker on remove clumsy as one needs to change profile (Mic1 and MIc2 does not help in selecting what might be good)...
Similarly: no profile contains the internal mic and headset mic, so if you start a call with headset mic (you need to select t he profile which lists headset) and then later unplug the HS: you will have no mic as the internal mic is in different profile.

There are rough edges with this imho, but it is not related to the Variant change at all.

I have a version which 'emulates' what legacy does by hiding the playback devices for the surround profiles, but I don't think that is the right thing to do.

If you think this is a good way to move forward, I will re-open the PR and see how we can make things better via PW and UIs for users?

Note:
there is also a strange thing with how the 5.1 channel UI test works:

SW button    -> physical speaker
--------------------------------
Front left   -> Front left
Front center -> Rear right
Front right  -> Front right
Rear left    -> Front center
Subwoofer    -> Rear left
Rear right   -> Subwoofer

The same machine at the same time with speaker-test -Dhw:0,3 -c6 -t wav plays all the channels to the correct speaker. So something goes wrong with the channel mapping that PW invents, but no idea what...

[ujfalusi]

@perexg, another thing I have observed with this variant change is that the mics starts to hoard the ConflictingDevices on the 5+1 an 7+1 variants, Device.Mic1, Device.Mic2 specifically:
hda-sof-variants-ucm.txt

It does not seam to affect functionality and I'm yet to figure out how to prevent such buildup of conflicts..

[ujfalusi]

@perexg, another thing I have observed with this variant change is that the mics starts to hoard the ConflictingDevices on the 5+1 an 7+1 variants, Device.Mic1, Device.Mic2 specifically: hda-sof-variants-ucm.txt

It does not seam to affect functionality and I'm yet to figure out how to prevent such buildup of conflicts..

If I put the ConflictingDevice settings in ucm2/HDA/HiFi-mic.conf to be wrapped under:

Variant."HiFi" {
}

Then only the devices under the "HiFi" verb have ConflictingDevices, "HiFi 5+1" and "HiFi 7+1" devices are all without this marker, I guess this is not good either, but again, does not seam to affect UI or spa-acp-tool presentation of profiles, devices.

[perexg]

I bet that the issue is alsa-lib variant code - the macros and variables should be "reset" for each variants to initial state. Actually they are preserved. Variables are mostly overwritten, but for macro array '[]' blocks, the new contents is appended, thus you see duplicated entries (equivalent to variant iteration). I'll fix that.

[ujfalusi]

@perexg, I think the channel mapping issue is identified and with https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2647 it is going to be sorted out.

for background and debugging with user see: thesofproject/linux#5627

I will re-open this PR as this is now the second user who hit the same issue that 5.1/7.1 is not available and then the channels got spread out 'randomly'
This and the PW patch will at least allow users to use LPCM for now and then we can look for better solution with UCM+PW and UI guys.

[ujfalusi]

@perexg, if https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4928 is implemented then we are not going to need variants at all, right? PW will ignore some or all information from UCM regarding to HDMI and will use ELD to magically present the surround configurations.

[perexg]

Yes, I already noted that the forced variants are not the best idea when we know the device parameters through ELD (handling also the device parameter changes through standard ALSA control API event mechanism).

Note that in Syntax 8 I added possibility to create Device Variants - https://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm__conf.html with other extensions to reduce the If complexity in future for the drivers like HDA supporting many hardware variants.

[Erick555]

This has the benefit that it will make it work right away. Even distros released this spring could get the fix. Pipewire work seems to be stuck at design decisions and it requires UI support from DE which will delay it even further. Meanwhile users of past several intel generations can't get surround sound output. I think it would be nice to get this done here, then calmly wait for ELD approach to finalize.

[perexg]

We may follow the SplitPCM application variable (feature handshake) -

alsa-ucm-conf/ucm2/common/pcm/split.conf

Line 55 in 4d9d7ad

# @SplitPCM - defined, return channel description using UCM values

For example: If "${var:@HDMIdirect}" is not set, define variants in UCM for this moment. It took more than two years to implement channel split in pipewire based on UCM configuration. The variable name may be improved (suggestions?).

EDIT: Changed variable name from HDMIvariants to HDMIdirect - it should be opposite meaning than I though.

[ujfalusi]

@perexg, the DeviceVariant is pretty powerful new addition, but in case of (SOF/HDA) HDMI it can create undesirable mesh of SectionDevices if we want to expose the features of the device.
HDMI via HDA can support 2/4/6/8 channels for playback, S16_LE, S32_LE, rate 32000...192000, so if we want to convey a subset of this via UCM, we will have quite an explosion of SectionDevices, no? Like 44.1_2.0, 48_2.0, 96_2.0, 44.1_5.0, 48_5.0, etc.

If we could have a flag for a SectionDevice to instruct the application (PW) to look at the PCM device/ELD/etc for information on what is supported?

[perexg]

HDMI via HDA can support 2/4/6/8 channels for playback, S16_LE, S32_LE, rate 32000...192000, so if we want to convey a subset of this via UCM, we will have quite an explosion of SectionDevices, no? Like 44.1_2.0, 48_2.0, 96_2.0, 44.1_5.0, 48_5.0, etc.

Yes, it's problematic. Maybe we can also add ELD parsing support to UCM to filter out the "unsupported" UCM devices, but there are other issues that UCM does not handle like plugging monitor when UCM is probed... So the best way is to handle this on the server side at the moment.

If we could have a flag for a SectionDevice to instruct the application (PW) to look at the PCM device/ELD/etc for information on what is supported?

To my knowledge, the current PW/PA automatically detects ELD elements through the control API associated to the given PCM device. I believe that presence of this element is enough to detect the HDMI/DP PCM device. So nothing else is required.