Intel SOF HDA: Lenovo m920sff support (Realtek ALC 233)

[perexg]

Description: An issue with the headphone detection (Speaker/Headphone auto-mute).

More info: thesofproject/linux#3088 and https://bugzilla.suse.com/show_bug.cgi?id=1188685

Mixer:

Simple mixer control 'Master',0
Simple mixer control 'Headphone',0       # Switch only
Simple mixer control 'Headphone+LO',0    # Volume only
Simple mixer control 'Speaker',0
Simple mixer control 'Front Mic',0
Simple mixer control 'Front Mic Boost',0
Simple mixer control 'Line Out',0        # Switch only
Simple mixer control 'Mic',0
Simple mixer control 'Mic Boost',0
Simple mixer control 'IEC958',0
Simple mixer control 'IEC958',1
Simple mixer control 'IEC958',2
Simple mixer control 'Capture',0
Simple mixer control 'Auto-Mute Mode',0
Simple mixer control 'Dmic0',0
Simple mixer control 'Dmic1 2nd',0
Simple mixer control 'Loopback Mixing',0
Simple mixer control 'PGA1.0 1 Master',0
Simple mixer control 'PGA2.0 2 Master',0
Simple mixer control 'PGA3.0 3 Master',0
Simple mixer control 'PGA4.0 4 Master',0
Simple mixer control 'PGA7.0 7 Master',0
Simple mixer control 'PGA8.0 8 Master',0
Simple mixer control 'PGA9.0 9 Master',0

Jacks:

name 'Mic Jack'
name 'Front Mic Jack'
name 'Line Out Jack'
name 'Front Headphone Jack'
name 'Speaker Phantom Jack'
name 'HDMI/DP,pcm=3 Jack'
name 'HDMI/DP,pcm=4 Jack'
name 'HDMI/DP,pcm=5 Jack'

[tibirna]

Thank you very much for taking this on.

I am sorry to take more of your time, but I am only a user of the drivers and tools that got involved in my bug report, so I have no idea how to test your changes.

It would very much help if you described the procedure needed to test your changes on my production machine (please keep in mind that this is a vanilla precompiled OpenSUSE 15.3 distribution installation, so I can add some development packages -- libraries, debug symbols etc. -- but it's not a linux driver development machine, it's a production machine in permanent use).

Thanks
Cristian

[perexg]

The test is very easy - just grab the latest contents from the PR #116 (use git pull or get tar ball - https://github.com/perexg/alsa-ucm-conf/archive/refs/heads/hplo-shared.zip ). When you have the recent alsa-ucm-conf tree somewhere, just create ucm2 symlink from /usr/share/alsa/ucm2 to your alsa-ucm-conf/ucm2 tree (rename the original directory as first) as root. Restart pulseaudio or pipewire and you should be able to test the new configuration.

[tibirna]

No success, unfortunately. The Line out is still joined with the headphones output, and they both output sound at the same time (line out doesn't turn off when headphones are connected). The original observation that the volume on the line out became very loud when connecting the headphones doesn't happen anymore.

Attached:

• the alsa-info report
• a proof of use of the git-extracted ucm2
• a screenshot of the KDE mixer reflecting the detected devices.

As you can note too, the devices seem to be in inverse order and the HDMI3 output is selected by default. I had to manually select the Line Output (on which the speakers are connected) to get sound.

A new behaviour that I don't have either with the dsp-driver is that poping up the KDE mixer dialog cuts (pauses?) the sound for about 2 seconds.

alsa-info-202111040943.txt

[perexg]

No success, unfortunately. The Line out is still joined with the headphones output, and they both output sound at the same time (line out doesn't turn off when headphones are connected). The original observation that the volume on the line out became very loud when connecting the headphones doesn't happen anymore.

I think that PA does not have resolved the issue with the conflicting devices. It's a long story and it seems that we are waiting for someone who can finish this.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/582
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/854
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/596

Please, show me output from alsaucm -c hw:PCH dump text (if not correct, replace PCH with your HDA card number or identifier) for the configuration verification.

As you can note too, the devices seem to be in inverse order and the HDMI3 output is selected by default. I had to manually select the Line Output (on which the speakers are connected) to get sound.

The HDMI devices have higher priority than analog, so they're picked first if the user does not override this settings (select another device).

A new behaviour that I don't have either with the dsp-driver is that poping up the KDE mixer dialog cuts (pauses?) the sound for about 2 seconds.

No idea, it's not relevant to the UCM configuration. It may be caused by the conflicting devices issue above.

[tibirna]

Sorry for the late reply. I need to reboot each time I have to test this. This is my production machine and voice call requirements don't allow me to go with non-functional sound config. Here is the output of `alsaucm -c hw:1 dump text` Thank you very much for your attention

…

On Thu, 4 Nov 2021 at 11:12, Jaroslav Kysela ***@***.***> wrote: No success, unfortunately. The Line out is still joined with the headphones output, and they both output sound at the same time (line out doesn't turn off when headphones are connected). The original observation that the volume on the line out became very loud when connecting the headphones doesn't happen anymore. I think that PA does not have resolved the issue with the conflicting devices. It's a long story and it seems that we are waiting for someone who can finish this. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/582 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/854 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/596 Please, show me output from 'alsaucm -c hw:PCH dump text' (if not correct, replace PCH with your HDA card number or identifier) for the configuration verification. As you can note too, the devices seem to be in inverse order and the HDMI3 output is selected by default. I had to manually select the Line Output (on which the speakers are connected) to get sound. The HDMI devices have higher priority than analog, so they're picked first if the user does not override this settings (select another device). A new behaviour that I don't have either with the dsp-driver is that poping up the KDE mixer dialog cuts (pauses?) the sound for about 2 seconds. No idea, it's not relevant to the UCM configuration. It may be caused by the conflicting devices issue above. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJOWDTL2R2VF7P2IAEZ5B3UKKPE3ANCNFSM5HK2F6FQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[perexg]

Unfortunately, the output is not visible.

[tibirna]

Sorry for this. I answered by email and visibly github mail-to-issue-ui brigde has some bugs.

Here it is.
alsaucm_out.txt

[alpernebbi]

In that alsaucm_out.txt I see "Headphone Jack" as Headphones' JackControl, but shouldn't it be "Front Headphone Jack" after #116? I suspect the "iface=CARD" specifier breaks it, as other ControlExists blocks without that appear to be working, maybe it should be removed.

Also, I see in the alsa-info output that both "Line Out Playback Switch" and "Headphone Playback Switch" are enabled. I think both of those switches are enabled initially (not by PulseAudio), and need to be disabled in verb init like in 5947dae and #48.

Using ConflictingDevice in this same-PCM configuration shouldn't be a problem for PA, you would have one joint output device with five ports (actually four, one of the last two may be missing):

• Headphones
• Line
• Speaker
• Headphones+Speaker
• Line+Speaker

With no chance of PA simultaneously enabling Headphones and Line. You can check the ports with pactl list sinks, please do tell if they're different. I hope the two things I mentioned above would fix the issue for you, but here are some ideas you can try out in case those aren't enough:

• Run pulseaudio --log-level=debug and plug things in/out and see if it really notices device changes and how it acts on them. Post the log here.
• Plug in both jacks, then manually switch the output port of the joint device from "Line" to "Headphones" and back to "Line". Then see if both or only one device outputs sound.
• Post the output of pa-info, before/after different jacks are plugged in/out.
• Remove .config/pulse/*-device-volumes.tdb to reset volume and port preferences.

(Not sure all those will help, but wanted to tell in advance to avoid extra reboots on your end.)

[perexg]

In that alsaucm_out.txt I see "Headphone Jack" as Headphones' JackControl, but shouldn't it be "Front Headphone Jack" after #116? I suspect the "iface=CARD" specifier breaks it, as other ControlExists blocks without that appear to be working, maybe it should be removed.

Thanks for this analysis @alpernebbi . The problem is different - the SectionDevice is evaluated before the If sequences, thus the variable is not set at the parse time. I moved to SectionDevice.Headphones to If block, so it should work now.

@tibirna : Could you retest, please, with the latest code in PR ?

[perexg]

In that alsaucm_out.txt I see "Headphone Jack" as Headphones' JackControl, but shouldn't it be "Front Headphone Jack" after #116? I suspect the "iface=CARD" specifier breaks it, as other ControlExists blocks without that appear to be working, maybe it should be removed.

Thanks for this analysis @alpernebbi . The problem is different - the SectionDevice is evaluated before the If sequences, thus the variable is not set at the parse time. I moved to SectionDevice.Headphones to If block, so it should work now.

It was another issue. There was missing If block in the False block. I fixed this in PR #116.

[tibirna]

Thank you very much for continuing to look into this. Very much appreciated.

There is progress, but unfortunately not full resolution.

Using the new ucm config provided, I can have sound be played only on the headphones as soon as I connect them. The line out port stops playing. Volume is reasonable on both the line out before connecting the headphones and on the headphones after connecting them.

Unfortunately, disconnecting the headphones doesn't turn back on the sound on line out port. Once I disconnected the headphones, on I was not able to get sound anymore, until I rebooted the computer.

I tried manually changing the port in the KDE pulse-audio UI, but I ended up in a situation where, while sound was still not emitted anywhere, my music app also stopped reacting to play/stop commands (as if there was no sound output device).

The port list in the KDE pulse-audio UI changes between "line out / speaker" and "line out / speaker / combined line out + headphones / headphones" when I connect/disconnect the headphones.

Hope these details help.

Thansk again.

[perexg]

Thank you for your tests. If you manually mute / unmute the Headphone / Line out switches using alsamixer (Space key) or amixer, can you recover from the silent state ? Both tools are command line tools (terminal).

[alpernebbi]

combined line out + headphones

Well this is quite a problem, and I don't know how your system ends up combining these conflicting devices. I hope my PulseAudio merge requests will prevent it from happening though.

[tibirna]

Thank you for your tests. If you manually mute / unmute the Headphone / Line out switches using alsamixer (Space key)
or amixer, can you recover from the silent state ? Both tools are command line tools (terminal).

After rebooting once more, I can now observe a more consistent behaviour:

• sound plays by default on Line Out
• connecting the headphones switches automatically the sound output to the Headphones port
• disconnecting the headphones switches the sound output to the first of the HDMI lines, which is not connected to anything
• manually switching back the the "Headphones" output (still present) and changing the port manually to "Line Out", restores the sound
• with the headphones connected, I can manually switch to "Line Out", "Speaker", "Headpones + Speaker" (??? -- and only the headphones have sound) or "Headphones" port. The effects on sound output are the expected ones (with the exception marked before).

So, in the end, things are even more closely to getting fixed than I thought initially. The only missing thing is now automatically switching back to "Line Out" when disconnecting the headphones.

Unfortunately, I can't tell why I see this difference from the first reboot. And I can't tell if this (somewhat better) behaviour is stable (or if the faulty blocking behaviour would rather occur in some unknown circumstances).

BTW, I didn't need to use alsamixer in the end. I tried it for completion, though, but I can't use it because of wrong permissions (even as root)

(18:08:07) [ctibirna@leto]:~> sudo alsamixer 
[sudo] password for root: 
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

cannot open mixer: Connection refused

Thanks again for your patience.

[tibirna]

combined line out + headphones

Well this is quite a problem, and I don't know how your system ends up combining these conflicting devices. I hope my PulseAudio merge requests will prevent it from happening though.

FWIW, as explained, the sound configuration used by OpenSUSE until their 15.2 version worked perfectly with this exact hardware configuration (at least for my needs). And I can still revert to that configuration in OpenSUSE 15.3 by passing options snd-intel-dspcfg dsp_driver=1 to the kernel config.

[alpernebbi]

disconnecting the headphones switches the sound output to the first of the HDMI lines, which is not connected to anything

In the last alsa-info output you sent, there are two HDMI jacks that claim to be plugged in (HDMI2 and HDMI3?). I believe the KDE UI hides unplugged/unavailable things and what you call "the first" here is one of those two, which would be consistent with PulseAudio trying to switch to the highest-priority available port when you disconnect the headphones. Then again, why would that port claim to be plugged-in when it's not? A bug somewhere else?

Also, try using pavucontrol as that shows unplugged/unavailable status pretty clearly.

"Speaker", "Headpones + Speaker" (??? -- and only the headphones have sound)

I think "Speaker" here is an internal speaker. There's supposed to be one based on this M920 SFF PSREF document. Does that work by itself when you unplug everything, maybe it's hardware-muted when you plug in anything?

So, in the end, things are even more closely to getting fixed than I thought initially. The only missing thing is now automatically switching back to "Line Out" when disconnecting the headphones.

I think #116 is pretty much complete now based on those results, since automatic switching may be explained as PA behaviour.

Unfortunately, I can't tell why I see this difference from the first reboot. And I can't tell if this (somewhat better) behaviour is stable (or if the faulty blocking behaviour would rather occur in some unknown circumstances).

I have no idea either. If that happens again, can you send the outputs of alsaucm -c hw:1 dump text and pa-info please?

BTW, I didn't need to use alsamixer in the end. I tried it for completion, though, but I can't use it because of wrong permissions (even as root)

You can try alsamixer -c 1.

FWIW, as explained, the sound configuration used by OpenSUSE until their 15.2 version worked perfectly with this exact hardware configuration (at least for my needs). And I can still revert to that configuration in OpenSUSE 15.3 by passing options snd-intel-dspcfg dsp_driver=1 to the kernel config.

Unfortunately you might have to keep using that workaround for a while if the better-working configuration isn't stable. (I'm assuming you didn't mean the combination port here, tell me otherwise.)

[perexg]

FWIW, as explained, the sound configuration used by OpenSUSE until their 15.2 version worked perfectly with this exact hardware configuration (at least for my needs). And I can still revert to that configuration in OpenSUSE 15.3 by passing options snd-intel-dspcfg dsp_driver=1 to the kernel config.

The old legacy configuration is fine, but we need to move to UCM because the hardware reports a digital microphone connected to DSP. This device is not available in old kernels. And you're right, the legacy driver can be forced with options snd-intel-dspcfg dsp_driver=1.

Your HDMI monitor (one is Lenovo L27q-30) has the headphone / speaker analog output (audio jack). We cannot sense the presence of the cable in this jack, because the HDMI protocol does not have this extension. EDIT: Perhaps the monitor may allow to disable the sound output and hide this information in ELD (for PC). Check the menu in the monitor.

The HDMI priorities makes sense for both scenarios:

1. user connected a monitor/TV with speakers (unfortunately some monitors have only headphone output and the HDMI protocol does not allow any presence sensing); users expect to get sound from monitor's speakers
2. the internal speaker in the laptop/desktop is the fallback and preferred output

If you don't like the current scenario, just set the priorities for the HDMI lower than for the Speaker (100) in /usr/share/alsa/ucm2/HDA-Intel/Hdmi.conf .