Improper default configuration of Realtek ALC 233 (used by Lenovo m920sff)

[tibirna]

(NOTE: the full downstream report for this is here: https://bugzilla.suse.com/show_bug.cgi?id=1188685)

After successful (and uneventful) installation of OpenSUSE 15.3 on my Lenovo m920sff, the sound card is auto-configured in such a way that sound is played in both the speakers and the headphones connected to the computer. Connecting the headphones doesn't silence the the speakers. The active sound device is presented in the UI with two profiles: Speaker and Headphones, with the 'Headphones" always selected (no matter if the headphones are actually plugged in or not). Manually switching the profile to 'Speaker' results in very loud output, with no volume control.

Updating the kernel to 5.13.5 and alsa, libasound2 and alsa-ucm-conf packages to their latest versions available for OpenSUSE was attempted with no detectable effect.

Outputs from lsmod and alsa-info.sh with the default configuration and with the options snd-intel-dspcfg dsp_driver=1 workaround (which indeed works around the reported issue) are available at the link at the top of this report.

[plbossart]

@tibirna are you saying that
options snd-intel-dspcfg dsp_driver=1 works for speakers/headphones
options snd-intel-dspcfg dsp_driver=3 does not work for speakers/headphones

I think this could be a UCM issue, or the controls for jack detection don't work properly.

[tibirna]

No. I am saying that the default configuration installed for my sound configuration using the SOF drivers results in the speaker and headphones to play at the same time, while using the workaround (options snd-intel-dspcfg dsp_driver=1) that deactivates the SOF drivers and uses the setup previously used by my linux distro (before introducing SOF) results in the proper behavior: the speaker is silenced when the headphones are connected, and only the headphones are playing. I was not aware of the dsp_driver=3 option and I don't know what that means.

[plbossart]

@tibirna I am not following at all.
dsp_driver =1 means forcing the use of the legacy HDaudio driver - which cannot support digital microphones.
dsp_driver=3 means forcing the use of the SOF driver - which does support digital microphones.

If you don't have digital microphones, then you have no reason to use SOF.
If you do and use the legacy HDaudio driver, you will not have capture support.

So in your previous OpenSuse setup or in the new one with dsp_driver=1, were you able to capture audio from the local microphones (with the headset not connected)?

[tibirna]

This conversation deviates from the actual topic, I think.

As can be seen by reading the output of alsa-info.sh https://bugzilla.suse.com/attachment.cgi?id=851210 attached to original issue report https://bugzilla.suse.com/show_bug.cgi?id=1188685, the snd_hda_intel kernel module detects automatically some digital mics on the Skylake+ platform (I can't tell if it's correct that it does so), so it automatically chooses the SOF drivers.

Let's forget for a moment about the manual dsp_driver=? config, that is something I used to work around the actual issue.

And the actual issue is that, for this particular configuration, the SOF driver does not get configured properly. It results in a setup in which both the speaker and the headphones are playing at the same time. This is the issue that the focus should be on.

No, the previous OpenSUSE setup (Leap 15.2) did not need a manual dsp_driver=1 configuration, it was automatically choosing the default dsp driver, which resulted in a proper sound configuration. To obtain that previous automatic setup in the latest OpenSUSE setup (Leap 15.3) I need to manually add the dsp_driver=1 option.

Thanks for your patience.

[plbossart]

to be clear: the previous setup was NOT "a proper sound configuration" - dmics were never handled.

Either you want to enable SOF or not. If yes, then please take a look at
https://thesofproject.github.io/latest/getting_started/index.html#debug-audio-issues-on-intel-platforms

HDaudio platforms have been supported for nearly two years now but there are still user-space issues with PulseAudio/UCM and SOF firmware not being aligned. These are mostly downstream/distro issues.

[tibirna]

I don't get to want to enable SOF or not. The snd_hda_intel kernel does the enabling automatically after detecting digital microphones.

Once the SOF driver is up, it should properly handle the separation between speaker and headphone outputs. This is the error that I'm reporting.

I reported all that I could at the distro level. The distro developer requested that I report the speaker/headphone output non-separation issue here, as it was his determination that that issue is caused by the SOF driver and not by distro configuration.

[plbossart]

@tiwai what makes you think it's an SOF driver issue? We're using the same code for the HDaudio codec management? My guess is that there's some issue with jack detection/UCM. There's nothing in the SOF code proper related to the codec, we only deal with the HDaudio DMAs/link.

[tiwai]

From the codec driver POV, there can't be any difference, so yes, it's likely an issue triggered by UCM profile.
My wild guess is that UCM isn't used for snd-hda-intel, while an incomplete UCM profile is used for SOF.

Maybe the handling of "Line Out" is missing...?

[plbossart]

Thanks @tiwai Indeed I have no idea what UCM should do with this configuration

	control.18 {
		iface CARD
		name 'Mic Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.19 {
		iface CARD
		name 'Front Mic Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.20 {
		iface CARD
		name 'Line Out Jack'
		value true <<<????
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.21 {
		iface CARD
		name 'Front Headphone Jack'
		value false
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}
	control.22 {
		iface CARD
		name 'Speaker Phantom Jack'
		value true <<<????
		comment {
			access read
			type BOOLEAN
			count 1
		}
	}

@tibirna any idea why the LineOut is detected? Is this how the speakers are connected?
also no idea what the phantom jack might be.

[tiwai]

AFAIK, the "Line Out" corresponds to the line-out jack on a dock (it may have both the line out and the headphone out jacks), and it's supposed to mute the built-in speaker automatically like the headphone jack, too.

The "Speaker Phantom Jack" is a pseudo jack control for built-in speaker pins, and basically it's only useful for PulseAudio, as the control always returns true.

[plbossart]

@tiwai I am confused with the jack layer. Can we actually see a difference and deal differently at the UCM layer between

a) single jack supporting either headphone or line out - mutual exclusion
b) two jacks supporting headphone on one and line out on the other - no mutual exclusion.

Thanks!

[tiwai]

It's possible to deal differently both cases in theory, but at least for PA, all outputs (that are assigned to a single device) are mutual exclusion, so there would be no difference, as far as I understand. So you can assume only the exclusive outputs for now.

My point is that there is no definition of Line Out at all in HD-audio profiles. That may explain the described behavior.

[plbossart]

I am not sure this is correct @tiwai. UCM has the notion of 'ConflictingDevice', that's what needs to be used in case there's a hardware limitation. If there are two separate jacks, the devices don't conflict. Maybe at the settings/PA level the routing only allows for one output at a time but that wouldn't be a UCM limitation.

Also in general the UCM support for SOF on HDaudio platform boils down to using <HDA-Intel/HiFi-analog.conf>
Maybe that's part of the issue, the LineOut is supported in another HDA-Intel/HiFi-dual.conf file. I am not sure how one chooses one or the other file.

Probably need to ask @perexg for help :-)

[tibirna]

Yes, the speakers are connected on the single jack available on the back plate of the m920sff. This was always detected as 'line out' by the different Linux installations. This machine also has a headphones-with-mic jack and a separate mic-only jack on the front plate.

…

On Thu., Aug. 12, 2021, 11:45 Pierre-Louis Bossart, < ***@***.***> wrote: Thanks @tiwai <https://github.com/tiwai> Indeed I have no idea what UCM should do with this configuration control.18 { iface CARD name 'Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.19 { iface CARD name 'Front Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.20 { iface CARD name 'Line Out Jack' value true <<<???? comment { access read type BOOLEAN count 1 } } control.21 { iface CARD name 'Front Headphone Jack' value false comment { access read type BOOLEAN count 1 } } control.22 { iface CARD name 'Speaker Phantom Jack' value true <<<???? comment { access read type BOOLEAN count 1 } } @tibirna <https://github.com/tibirna> any idea why the LineOut is detected? Is this how the speakers are connected? also no idea what the phantom jack might be. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3088 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJOWDX66FAN5DSNKTQ6MJDT4PUDHANCNFSM5B2DFLEA> . 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&utm_campaign=notification-email> .

[tiwai]

I am not sure this is correct @tiwai. UCM has the notion of 'ConflictingDevice', that's what needs to be used in case there's a hardware limitation. If there are two separate jacks, the devices don't conflict. Maybe at the settings/PA level the routing only allows for one output at a time but that wouldn't be a UCM limitation.

That's what I meant, too :) UCM itself can distinguish both cases but PA deals always exclusively, so there is practically no difference.

[plbossart]

The only thing I can suggest is to try this

diff --git a/ucm2/sof-hda-dsp/HiFi.conf b/ucm2/sof-hda-dsp/HiFi.conf
index 2c02c15..2fe4206 100644
--- a/ucm2/sof-hda-dsp/HiFi.conf
+++ b/ucm2/sof-hda-dsp/HiFi.conf
@@ -4,7 +4,7 @@ SectionVerb {
        Value.TQ "HiFi"
 }
 
-<HDA-Intel/HiFi-analog.conf>
+<HDA-Intel/HiFi-dual.conf>
 
 If.monomic.After.SectionDevice "Mic1"
 

This should enable a line out.

[perexg]

This should enable a line out.

This configuration is for different hardware (multiple HDA codecs using multiple PCM devices).

The use case for this HDA configuration should be written from scratch (different mixer controls like 'Front Mic', 'Line Out', 'Headphone+LO' etc.):

Simple mixer control 'Master',0
Simple mixer control 'Headphone',0
Simple mixer control 'Headphone+LO',0
Simple mixer control 'Speaker',0
Simple mixer control 'Front Mic',0
Simple mixer control 'Front Mic Boost',0
Simple mixer control 'Line Out',0
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

PA does not use the legacy probe when UCM is used, so the configuration must be described in UCM correctly.

[plbossart]

The use case for this HDA configuration should be written from scratch (different mixer controls like 'Front Mic', 'Line Out', 'Headphone+LO' etc.):

I wouldn't even know where to start...

[perexg]

@tibirna : Could you follow alsa-project/alsa-ucm-conf#114 and test alsa-project/alsa-ucm-conf#116 ? It looks like an UCM issue which is not related to the SOF project. I propose to close this issue here.

[plbossart]

closing, no update in 10 months and not an SOF issue proper