thesofproject
[BUG] No HDMI surround output on Intel Lunar Lake-M HD Audio
Describe the bug On Dell Pro Plus laptop with integrated Intel Lunar Lake-M HD soundcard there are no HDMI surround outputs or profiles. There are only HDMI stereo outputs/profiles for speakers, headphones, headset, etc.
After setting options snd-intel-dspcfg dsp_driver=1 to force legacy intel HDA driver the HDMI surround profiles appear but they are shown as unplugged with no available output device. I was able to output 6 channel sound when forcing the output with speaker-test -c 6 -D hw:0,3 -r 48000 -p 100000 -t wav but that's all.
Moreover, in legacy mode internal speakers device/profile disappears so it's not possible to use them at all.
I found 3 year old issue where it was said it's known limitation that won't be fixed on old intel platforms but it still happen on brand new intel platform as shown above. Moreover, the suggested workaround of forcing Intel HDAudio doesn't exactly work for the issue and it creates other problems.
My setup works out of the box on older device with Intel HDAudio soundcard.
To Reproduce
speaker-test -c 6
Reproduction Rate all the time.
Expected behavior A clear and concise description of what you expected to happen.
Impact showstopper
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: 6.17.9
- SOF: v2025.05.1
- Name of the topology file
- Topology: intel/sof-ipc4-tplg/sof-lnl-cs42l43-l0.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: Linux, Lunar Lake, Dell Pro Plus
Screenshots or console output (EDIT: (uploaded new also-info logs for clarity)
sof_hdmi-plugged_ucp-on_alsa-info.txt
sof-hdmi-plugged_ucp-off_alsa-info.txt
legacy-intel-hda_hdmi-plugged_ucp-on_alsa-info.txt
legacy-intel-hda_hdmi-plugged_ucp-off_alsa-info.txt
@ujfalusi @jsarha is the use case we need the 5.1 HDMI receiver to be inserted 1st in order to read the EID channel data and mark this configuration as supported by the PCM device ?
After investigating this further I found that disabling ALSA Use Case Manager in wireplumber config makes HDMI surround profiles to appear while using sof kernel driver. The are also correctly detected as active (plugged) when HDMI cable is attached (that doesn't work for HDA driver). With following snippet HDMI surround playback works out of the box on my device:
~/.config/wireplumber/wireplumber.conf.d/99-disable-alsa-ucp.conf
monitor.alsa.properties = {
alsa.use-ucm = false
}
Hover this disables internal speakers (card is shown is inactive with and without HDMI cable attached, there are no available profiles other than HDMI. This is similar effect to using Intel HDA driver.
Disabling ucm while using Intel HDA driver has no effect - HDMI outputs ares still shown as unplugged (cable attached) and internal speakers are gone.
Updates alsa-info logs in first post.
It seems there was attempt to fix it in alsa-ucm but it didn't get merged: https://github.com/alsa-project/alsa-ucm-conf/pull/633
I also found related threads
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4755
https://github.com/thesofproject/linux/issues/5461
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4928
Intel Lunar Lake-M
Kernel: 6.17.9
Revert to kernel 6.17.7, this is a regression in 6.17.8 for devices using the Lunar Lake sound card.
Do you mean surround profiles will appear in 6.17.7 with sof driver? Is 6.18.1 affected by regression?
@Erick555, if you use the audio card directly with:
speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav
Then it should work (given the device connected has support for 6 channel).
Your laptop is using soundwire for analog audio, it is not supported by the legacy stack, this is why you loose everything but HDMI by switching to it.
To add to the list of related issues: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4976
While the multichannel (and passthrough) audio works in ALSA level for LNL it is masked for users by how UCM designed to expose audio use cases and how these use cases are parsed by pipewire and pulseaudio and finally how this is presented by user interfaces (KDE/GNOME/etc).
While https://github.com/alsa-project/alsa-ucm-conf/pull/633 can provide the surround profiles it will - in my opinion - creates a mess in UI level which makes navigating between profiles far from intuitive to say the least.
We are trying to figure out with upper stack guys on how to make this right but the progress slowed down recently I guess because of other priorities for them.
Yeah, I found those discussions myself. From user POV convoluted UI is still better than nothing and as I see, surround profiles are broken for all intel generations released in past several years. I think perfect may be the enemy of the good here.
The UI issue may not be even related directly to surround profiles but to the fact the Headphones, Headset, Mic combinations are attached to every profile. I think surround profiles could be added first since it's known how to do that then UI can be tweaked later when some consensus is achieved. If it requires coordination between alsa-ucm, pipewire and DE then it may take another several years to get the result into most linux distros.
@Erick555, while the UCM patch gives the profiles for the surround, on my setup the UI's channel mapping got completely off: https://github.com/thesofproject/linux/issues/5461#issuecomment-3481336912 The speakers are shuffled a bit while from command line (which I use for firmware and kernel testing) all channels are in correct position. I don't know the PW code that well to guess where the chmap goes corrupt. I'll file a new issue for this and see if it can be addressed and we can push for the UCM variants to be applied so at least you can have a way to select surround, but a proper way still need to be found for UCM/PW/UIs.
You are right, the mapping is messed up with the ucm patch. The only workaround remains disabling ucm which disables internal speakers.
@Erick555, thank you for confirming :(
can you check this:
monitor.alsa.rules = [
{
# Matches all SOF alsa sinks
matches = [
{
api.alsa.card.name = "~sof-.*"
node.name = "~alsa_output.*"
}
]
actions = {
update-props = {
api.alsa.use-chmap = false
}
}
}
]
inside of ~/.config/wireplumber/wireplumber.conf.d/50-sof-config.conf and reboot with the surround variant UCM patch and see if the channels are still all over the place?
Withe the above config and ucm patch from https://github.com/alsa-project/alsa-ucm-conf/pull/633 channel mapping is still messed up unfortunately
To complete above, using speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav also messes mapping with above ucm patch and without the patch. Only disabling ucm makes it work correctly.
@Erick555, this is really odd, I have tested this again on an LNL laptop which is connected to my AVR and everything is coming from the correct place with:
~# speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav
speaker-test 1.2.14
Playback device is hw:0,5
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 349525
Period size range from 480 to 174762
Requested period time 100000 us
Periods = 4
was set period_size = 4800
was set buffer_size = 19200
0 - Front Left
4 - Front Center
1 - Front Right
3 - Rear Right
2 - Rear Left
5 - LFE
In KDE's speaker test UI the position of speakers are wrong as in my comment in https://github.com/thesofproject/linux/issues/5461#issuecomment-3481336912
But applying the api.alsa.use-chmap = false via ~/.config/wireplumber/wireplumber.conf.d/50-sof-config.conf and log out, log in and all speaker are in correct place when I select the Surround 5.1 profile.
This is with 6.17.9-artix1-1 kernel.
Note: when you use hw:0,5 (or plughw:0,5) then UCM is not used, ALSA PCM device is used directly, it should not in theory have any effect on how it works.
I tested with Linux 6.18.1 and KDE 6.5.4. I tried 5.1 and 7.1 profiles with speakers and with headphones. The order was wrong in the KDE UI and with ALSA PCM. Disabling ucm fixed it in both. I test with 7.1 LPCM DAC with 5.1 speakers attached.
I use systemctl --user restart pipewire pipewire-pulse wireplumber cmd instead of logout/reboot after config switch.
@Erick555, how do you 'disable' UCM?
can you share the output from speaker-test when it prints which channel is used for which speaker when they are in mixed (UCM enabled?) and when they are in correct place (UCM disabled?).
What profile you select in UI should not in any way have effect on speaker-test -Dhw:0,5
With the 5.1 and 7.1 variant profiles the speaker/headphone should be still stereo.
What is troubling that in ALSA level (speaker-test -Dhw:0,5) the mapping is incorrect for you when using the SOF stack and they are correct with legacy HDA? can you provide the output of speaker-test for both cases, I cannot see atm how they can behave differently as SOF is using the generic HDA library, we 'just' have the DSP stuck in between the host and link DMA.
Right now I'm disabling ucm with following wireplumber conf:
monitor.alsa.rules = [
{
# Matches all SOF alsa sinks
matches = [
{
api.alsa.card.name = "~sof-.*"
}
]
actions = {
update-props = {
api.alsa.use-ucm = false
}
}
}
]
I show more tests later when I get access to my surround setup.
What profile you select in UI should not in any way have effect on speaker-test -Dhw:0,5 With the 5.1 and 7.1 variant profiles the speaker/headphone should be still stereo.
Yes, profile selection doesn't have effect on speaker-test but ucm state somewhat has effect, I don't know why. With your patch I have duplicate 5.1/7.1 profiles - they're described as HDMI1-3,mic,speakers and HDMI1-3,mic,headphones (or headset I don't remember). I test them both with same effect. There's no speaker output when choosing the profile with speakers to be clear. It's just UI weirdness that was discussed elsewhere.
@Erick555, yes, the UCM variant way will do that, it is one of the reasons I have decided to close it. Other options were not great either, like creating separate HDMI SectionDevices for stereo, surround 5.1 and 7.1, all will increase the permutations in profiles. This is known by the UCM/pipewire devs and we are trying to figure things out, but no conclusion from their side yet.
I'll wait for the output prints from speaker-test, it might help us understand how we can get this right on your setup - I know it does no help you, but it sort of works on my end and I have no idea what causes your setup to behave differently.
I retested this again and out of sudden everything works like it should - all speaker-test tests show correct mapping. Also ucm2 patch + api.alsa.use-chmap = false show correct mapping in UI. I tried switching DAC off and on , rebooting but everything works today. I don't know wth was happening yesterday.
Below are test results, all identical:
❯ speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav (default)
speaker-test 1.2.14
Playback device is hw:0,5
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 349525
Period size range from 480 to 174762
Requested period time 100000 us
Periods = 4
was set period_size = 4800
was set buffer_size = 19200
0 - Front Left
4 - Front Center
1 - Front Right
3 - Rear Right
2 - Rear Left
5 - LFE
❯ speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav (using ucm2 patch)
speaker-test 1.2.14
Playback device is hw:0,5
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 349525
Period size range from 480 to 174762
Requested period time 100000 us
Periods = 4
was set period_size = 4800
was set buffer_size = 19200
0 - Front Left
4 - Front Center
1 - Front Right
3 - Rear Right
2 - Rear Left
5 - LFE
❯ speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav (ucm2 patch + chmap=false
speaker-test 1.2.14
Playback device is hw:0,5
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 349525
Period size range from 480 to 174762
Requested period time 100000 us
Periods = 4
was set period_size = 4800
was set buffer_size = 19200
0 - Front Left
4 - Front Center
1 - Front Right
3 - Rear Right
2 - Rear Left
5 - LFE
❯ speaker-test -c 6 -D hw:0,5 -r 48000 -p 100000 -t wav (ucm2=false)
speaker-test 1.2.14
Playback device is hw:0,5
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 349525
Period size range from 480 to 174762
Requested period time 100000 us
Periods = 4
was set period_size = 4800
was set buffer_size = 19200
0 - Front Left
4 - Front Center
1 - Front Right
3 - Rear Right
2 - Rear Left
5 - LFE
In my setup each profile is duplicated but it's rather minor issue. Considering stereo profiles are also duplicated it shouldn't be blocker to enable surround profiles this way IMO. Polishing UI may be done later.
In the end I found acceptable workaround. Thx for helping.
@ujfalusi Sorry for the off-topic but do you know something about recent regression regarding no sound output from headphones with kernel newer than 6.17.7 on LNL platform? I guess this is regression that @bneils mentioned earlier?
I found two issues talked elsewhere 1, 2. Before I open new issue here I wanted to check if it's known already
@ujfalusi Sorry for the off-topic but do you know something about recent regression regarding no sound output from headphones with kernel newer than 6.17.7 on LNL platform? I guess this is regression that @bneils mentioned earlier?
No, I have no heard of a regression, but looking at the links they all seam to have Cirrus codec and all involves Jack muted and this might be fixed by: https://lore.kernel.org/linux-sound/[email protected]/
I had a wrong patch which fixed on my machine, the commit message explains what I have seen: https://lore.kernel.org/linux-sound/[email protected]/
I found two issues talked elsewhere 1, 2. Before I open new issue here I wanted to check if it's known already
I believe https://lore.kernel.org/linux-sound/[email protected]/ will fix this as soon as it is picked and backported to stable, but if you can try it and see if that helps...
@Erick555, it might be moon phase? Thank you for your time on testing and thank you for the great length of details and information. It looks like that the Surround variants + no-chmap can be an intermediate solution to get at something working, even if it is not an ideal.
I'll try to figure out if this can be done purely from UCM (to force PW to use no-chmap for SOF cards) or we need PW changes as well.
Thank you again for the the information.
I believe https://lore.kernel.org/linux-sound/[email protected]/ will fix this as soon as it is picked and backported to stable, but if you can try it and see if that helps...
I rebuild 6.18.2 kernel with that patch (had to pick some other as it didn't apply cleanly) and it fixed the issue, thx.