[alsa-devel] [PATCH 1/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk subdevice id
fixes the pci subsystem device ids for the "Thinkpad X1 Carbon 7th" and "Thinkpad X1 Yoga 7th" quirks.
My machine reports the following: dmidecode -t system Manufacturer: LENOVO Product Name: 20QDCTO1WW Version: ThinkPad X1 Carbon 7th
lspci -s 1f.3 -vnn 00:1f.3 Audio device [0403]: Intel Corporation Cannon Point-LP High Definition Audio Controller [8086:9dc8] (rev 11) (prog-if 80) Subsystem: Lenovo Cannon Point-LP High Definition Audio Controller [17aa:2292]
/proc/asound/card0/codec#0 Subsystem Id: 0x17aa2293
Notice the different subsystem device ids between pci info and codec info.
commit d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") added a quirk meant for the X1 Carbon but used device id 0x2293. Note that this does not match the PCI SSID but it matches the codec SSID. commit 54a6a7dc107d ("ALSA: hda/realtek - Add quirk for the bass speaker on Lenovo Yoga X1 7th gen") added a quirk meant for the X1 Yoga but used subdevice id 0x2292, the PCI SSID used on the X1 Carbon.
Given that in snd_hdac_device_init() quirks are first matched by PCI SSID and then, if there is no match, by codec SSID, the net result is that the quirk labelled "Thinkpad X1 Yoga 7th" now gets applied on the X1 Carbon. Example from my machine (an X1 Carbon, not Yoga): [ 15.817637] snd_hda_codec_realtek hdaudioC0D0: ALC285: picked fixup Thinkpad X1 Yoga 7th (PCI SSID)
Therefore, fix the subdevice id for the "ThinkPad X1 Carbon 7th" quirk.
Note that looking through the lspci outputs collected at https://github.com/linuxhw/LsPCI/tree/master/Notebook/Lenovo/ThinkPad all X1 Carbon there have an Audio device with PCI SSID 0x2292, which matches with the output from my machine.
This leaves the question of what to do with the quirk labelled "Thinkpad X1 Yoga 7th".
From email discussions, it seems that the author of commit 54a6a7dc107d
("ALSA: hda/realtek - Add quirk for the bass speaker on Lenovo Yoga X1 7th gen") did not have a device to test the changes. I don't have an X1 Yoga either and I did not find a sample lspci listing for it online. Therefore, the best course of action seems to be to remove that quirk. In the best case, the quirk for the X1 Carbon will match the X1 Yoga (via PCI SSID or codec SSID). In the worst case, it will not and someone who actually has such a machine should come forth with concrete data about subsystem ids and needed quirks.
Fixes: d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") Fixes: 54a6a7dc107d ("ALSA: hda/realtek - Add quirk for the bass speaker on Lenovo Yoga X1 7th gen") Link: https://lore.kernel.org/alsa-devel/20200210025249.GA2700@f3/ Cc: Jaroslav Kysela perex@perex.cz Cc: Kailang Yang kailang@realtek.com Signed-off-by: Benjamin Poirier benjamin.poirier@gmail.com --- sound/pci/hda/patch_realtek.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4770fb3f51fb..05d44df2008e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7268,8 +7268,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x224c, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x224d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x225d, "Thinkpad T480", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), - SND_PCI_QUIRK(0x17aa, 0x2292, "Thinkpad X1 Yoga 7th", ALC285_FIXUP_SPEAKER2_TO_DAC1), - SND_PCI_QUIRK(0x17aa, 0x2293, "Thinkpad X1 Carbon 7th", ALC285_FIXUP_SPEAKER2_TO_DAC1), + SND_PCI_QUIRK(0x17aa, 0x2292, "Thinkpad X1 Carbon 7th", ALC285_FIXUP_SPEAKER2_TO_DAC1), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
As a result of commit d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen"), the maximum sound output level on my machine, an X1 Carbon, was reduced to ~60% of its previous level.
This laptop model has two sets of stereo speakers: Front and Bass (aka Rear in some contexts). Before commit d2cd795c4ece, volume control was commonly ineffective (using the Master slider in alsa or pulseaudio apparently had little effect or alternated between mute or max with nothing in between - more details below) commit d2cd795c4ece added quirk ALC285_FIXUP_SPEAKER2_TO_DAC1 which resulted in assigning both sets of speakers to the same DAC, bringing the two sets of speakers under one effective volume control but also lowering the max output volume noticeably.
Fix this by changing the quirk so that each set of speakers can be controlled individually and the max output volume is restored to what it was before commit d2cd795c4ece.
Since there is no documentation about the audio codec, here is some detailed information about the result of applying different quirks. DAC connection (which is what's affected by the quirk) is reported as found in /proc/asound/card0/codec#0, Node 0x17. pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
no quirk Loud max output volume DAC connection Connection: 3 0x02 0x03 0x06* Controls in alsamixer Master controls front speakers only. Speaker controls front speakers only. Bass Speaker is a toggle that mutes everything. PCM controls all speakers. There is no "Front" mixer. Controls in pavucontrol "Front Left"/"Front Right" sliders work as expected. "Rear Left"/"Rear Right" sliders seem to operate in a non-linear fashion such that most values above 0% result in max volume output. -> Because the bass speakers (Rear) are more powerful, the net effect is that when the channels are linked into a single slider, it seems like it has just two modes: mute or max. ALC285_FIXUP_SPEAKER2_TO_DAC1 Weak (~60%) max output volume DAC connection Connection: 3 0x02* 0x03 0x06 In-driver Connection: 1 0x02 Controls in alsamixer Master controls all four speakers. Speaker controls all four speakers. Bass Speaker is a toggle that mutes everything. PCM controls all four speakers. There is no "Front" mixer. Controls in pavucontrol "Front Left"/"Front Right" sliders have no effect. "Rear Left"/"Rear Right" sliders control both front and bass speakers. -> Volume control is effective but it's not possible to control front and bass speakers individually. ALC295_FIXUP_DISABLE_DAC3 Loud max output volume DAC connection Connection: 3 0x02 0x03* 0x06 In-driver Connection: 2 0x02 0x03 Controls in alsamixer Master controls all speakers. Speaker is a toggle that mutes everything. Bass Speaker controls bass speakers only. PCM controls all speakers. Front controls front speakers only. Controls in pavucontrol "Front Left"/"Front Right" sliders control front speakers only. "Rear Left"/"Rear Right" sliders control bass speakers only. -> Volume control is effective and it's possible to control each of the four speakers individually.
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
Fixes: d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") Link: https://lore.kernel.org/alsa-devel/20200210025249.GA2700@f3/ Cc: Jaroslav Kysela perex@perex.cz Cc: Kailang Yang kailang@realtek.com Signed-off-by: Benjamin Poirier benjamin.poirier@gmail.com --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 05d44df2008e..3171da10123e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7268,7 +7268,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x224c, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x224d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x225d, "Thinkpad T480", ALC269_FIXUP_LIMIT_INT_MIC_BOOST), - SND_PCI_QUIRK(0x17aa, 0x2292, "Thinkpad X1 Carbon 7th", ALC285_FIXUP_SPEAKER2_TO_DAC1), + SND_PCI_QUIRK(0x17aa, 0x2292, "Thinkpad X1 Carbon 7th", ALC295_FIXUP_DISABLE_DAC3), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
Dne 11. 02. 20 v 6:56 Benjamin Poirier napsal(a):
As a result of commit d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen"), the maximum sound output level on my machine, an X1 Carbon, was reduced to ~60% of its previous level.
This laptop model has two sets of stereo speakers: Front and Bass (aka Rear in some contexts). Before commit d2cd795c4ece, volume control was commonly ineffective (using the Master slider in alsa or pulseaudio apparently had little effect or alternated between mute or max with nothing in between - more details below) commit d2cd795c4ece added quirk ALC285_FIXUP_SPEAKER2_TO_DAC1 which resulted in assigning both sets of speakers to the same DAC, bringing the two sets of speakers under one effective volume control but also lowering the max output volume noticeably.
Fix this by changing the quirk so that each set of speakers can be controlled individually and the max output volume is restored to what it was before commit d2cd795c4ece.
Since there is no documentation about the audio codec, here is some detailed information about the result of applying different quirks. DAC connection (which is what's affected by the quirk) is reported as found in /proc/asound/card0/codec#0, Node 0x17. pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
no quirk Loud max output volume DAC connection Connection: 3 0x02 0x03 0x06* Controls in alsamixer Master controls front speakers only. Speaker controls front speakers only. Bass Speaker is a toggle that mutes everything. PCM controls all speakers. There is no "Front" mixer. Controls in pavucontrol "Front Left"/"Front Right" sliders work as expected. "Rear Left"/"Rear Right" sliders seem to operate in a non-linear fashion such that most values above 0% result in max volume output. -> Because the bass speakers (Rear) are more powerful, the net effect is that when the channels are linked into a single slider, it seems like it has just two modes: mute or max. ALC285_FIXUP_SPEAKER2_TO_DAC1 Weak (~60%) max output volume DAC connection Connection: 3 0x02* 0x03 0x06 In-driver Connection: 1 0x02 Controls in alsamixer Master controls all four speakers. Speaker controls all four speakers. Bass Speaker is a toggle that mutes everything. PCM controls all four speakers. There is no "Front" mixer. Controls in pavucontrol "Front Left"/"Front Right" sliders have no effect. "Rear Left"/"Rear Right" sliders control both front and bass speakers. -> Volume control is effective but it's not possible to control front and bass speakers individually. ALC295_FIXUP_DISABLE_DAC3 Loud max output volume DAC connection Connection: 3 0x02 0x03* 0x06 In-driver Connection: 2 0x02 0x03 Controls in alsamixer Master controls all speakers. Speaker is a toggle that mutes everything. Bass Speaker controls bass speakers only. PCM controls all speakers. Front controls front speakers only. Controls in pavucontrol "Front Left"/"Front Right" sliders control front speakers only. "Rear Left"/"Rear Right" sliders control bass speakers only. -> Volume control is effective and it's possible to control each of the four speakers individually.
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
You should also test PA with UCM.
Thanks, Jaroslav
Fixes: d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") Link: https://lore.kernel.org/alsa-devel/20200210025249.GA2700@f3/ Cc: Jaroslav Kysela perex@perex.cz Cc: Kailang Yang kailang@realtek.com Signed-off-by: Benjamin Poirier benjamin.poirier@gmail.com
sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 05d44df2008e..3171da10123e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7268,7 +7268,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x224c, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x224d, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x225d, "Thinkpad T480", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
- SND_PCI_QUIRK(0x17aa, 0x2292, "Thinkpad X1 Carbon 7th", ALC285_FIXUP_SPEAKER2_TO_DAC1),
- SND_PCI_QUIRK(0x17aa, 0x2292, "Thinkpad X1 Carbon 7th", ALC295_FIXUP_DISABLE_DAC3), SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY), SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
On 2020/02/11 08:40 +0100, Jaroslav Kysela wrote: [...]
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Front speakers are fixed to 0x02. Node 0x14 Connection: 1 0x02
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each channel individually:
pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with UCM.
Hi,
Speaker 2 connect to DAC 0x2 was Lenovo requested. This was tune for EQ setting. I didn't know more for this.
BR, Kailang
-----Original Message----- From: Benjamin Poirier benjamin.poirier@gmail.com Sent: Tuesday, February 11, 2020 4:16 PM To: Jaroslav Kysela perex@perex.cz Cc: Takashi Iwai tiwai@suse.de; Kailang kailang@realtek.com; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk value
On 2020/02/11 08:40 +0100, Jaroslav Kysela wrote: [...]
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume
control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Front speakers are fixed to 0x02. Node 0x14 Connection: 1 0x02
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each channel individually:
pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with UCM.
------Please consider the environment before printing this e-mail.
On Tue, 11 Feb 2020 10:10:50 +0100, Kailang wrote:
Hi,
Speaker 2 connect to DAC 0x2 was Lenovo requested. This was tune for EQ setting. I didn't know more for this.
Thanks, that was my expectation, too. Applying EQ to built-in speakers is an oft-seen workaround for laptops to avoid the possible hardware damage.
Now the question is whether this obvious level of lowering is the expected result.
Kailang, could you try to ask Lenovo about it?
Takashi
BR, Kailang
-----Original Message----- From: Benjamin Poirier benjamin.poirier@gmail.com Sent: Tuesday, February 11, 2020 4:16 PM To: Jaroslav Kysela perex@perex.cz Cc: Takashi Iwai tiwai@suse.de; Kailang kailang@realtek.com; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk value
On 2020/02/11 08:40 +0100, Jaroslav Kysela wrote: [...]
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume
control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Front speakers are fixed to 0x02. Node 0x14 Connection: 1 0x02
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each channel individually:
pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with UCM.
------Please consider the environment before printing this e-mail.
-----Original Message----- From: Takashi Iwai tiwai@suse.de Sent: Tuesday, February 11, 2020 5:20 PM To: Kailang kailang@realtek.com Cc: Benjamin Poirier benjamin.poirier@gmail.com; Jaroslav Kysela perex@perex.cz; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk value
On Tue, 11 Feb 2020 10:10:50 +0100, Kailang wrote:
Hi,
Speaker 2 connect to DAC 0x2 was Lenovo requested. This was tune for EQ setting. I didn't know more for this.
Thanks, that was my expectation, too. Applying EQ to built-in speakers is an oft-seen workaround for laptops to avoid the possible hardware damage.
Now the question is whether this obvious level of lowering is the expected result.
Kailang, could you try to ask Lenovo about it?
Yes, this is expected. I confirm this with our Lenovo AE.
Takashi
BR, Kailang
-----Original Message----- From: Benjamin Poirier benjamin.poirier@gmail.com Sent: Tuesday, February 11, 2020 4:16 PM To: Jaroslav Kysela perex@perex.cz Cc: Takashi Iwai tiwai@suse.de; Kailang kailang@realtek.com; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk value
On 2020/02/11 08:40 +0100, Jaroslav Kysela wrote: [...]
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume
control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Front speakers are fixed to 0x02. Node 0x14 Connection: 1 0x02
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each
channel individually:
pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with
UCM.
------Please consider the environment before printing this e-mail.
-----Original Message----- From: Takashi Iwai tiwai@suse.de Sent: Tuesday, February 11, 2020 5:20 PM To: Kailang kailang@realtek.com Cc: Benjamin Poirier benjamin.poirier@gmail.com; Jaroslav Kysela perex@perex.cz; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk value
On Tue, 11 Feb 2020 10:10:50 +0100, Kailang wrote:
Hi,
Speaker 2 connect to DAC 0x2 was Lenovo requested. This was tune for EQ setting. I didn't know more for this.
Thanks, that was my expectation, too. Applying EQ to built-in speakers is an oft-seen workaround for laptops to avoid the possible hardware damage.
Now the question is whether this obvious level of lowering is the expected result.
Kailang, could you try to ask Lenovo about it?
I have confirmed with our Lenovo AE.
Takashi
BR, Kailang
-----Original Message----- From: Benjamin Poirier benjamin.poirier@gmail.com Sent: Tuesday, February 11, 2020 4:16 PM To: Jaroslav Kysela perex@perex.cz Cc: Takashi Iwai tiwai@suse.de; Kailang kailang@realtek.com; alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] ALSA: hda/realtek - Fix Lenovo Thinkpad X1 Carbon 7th quirk value
On 2020/02/11 08:40 +0100, Jaroslav Kysela wrote: [...]
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume
control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Front speakers are fixed to 0x02. Node 0x14 Connection: 1 0x02
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each
channel individually:
pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with
UCM.
------Please consider the environment before printing this e-mail.
Dne 11. 02. 20 v 9:16 Benjamin Poirier napsal(a):
On 2020/02/11 08:40 +0100, Jaroslav Kysela wrote: [...]
In summary, Node 0x17 DAC connection 0x3 offers the loudest max volume and the most detailed mixer controls. That connection is obtained with quirk ALC295_FIXUP_DISABLE_DAC3. Therefore, change the ThinkPad X1 Carbon 7th to use ALC295_FIXUP_DISABLE_DAC3.
The volume split (individual volume control) will cause trouble for the UCM volume control at the moment which is the target for this device to get the digital microphone working. If there is no possibility to share DAC, it would be probably more nice to join the volume control in the driver.
Have you tried to use 0x03 as source for all four speakers?
Front speakers are fixed to 0x02. Node 0x14 Connection: 1 0x02
Yes, you're right. I forgot that.
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each channel individually:
Yes, but does the volume control work (does PA change the appropriate ALSA mixer volume)? Sometimes, it's difficult to see the difference between soft volume attenuation and the hardware volume control.
pavucontrol controls are reported with the device configured with the "Analog Surround 4.0 Output" profile.
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with UCM.
Just install the latest pulseaudio (latest from repo), alsa-lib and alsa-ucm-conf (also from repo). If pulseaudio detects UCM, it has the preference.
Jaroslav
On 2020/02/11 10:35 +0100, Jaroslav Kysela wrote:
Dne 11. 02. 20 v 9:16 Benjamin Poirier napsal(a):
[...]
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each channel individually:
Yes, but does the volume control work (does PA change the appropriate ALSA mixer volume)? Sometimes, it's difficult to see the difference between soft volume attenuation and the hardware volume control.
I see what you mean. When set to the "Analog Surround 4.0 Output", pulseaudio didn't change the "Bass Speaker" mixer (always at 0dB gain). It used a combination of Master, Front and sometimes PCM mixers to control all four speakers.
For example: pacmd list-sinks name: <alsa_output.pci-0000_00_1f.3.analog-surround-40> volume: front-left: 10349 / 16% / -48.09 dB, front-right: 39377 / 60% / -13.27 dB, rear-left: 23979 / 37% / -26.20 dB, rear-right: 47974 / 73% / -8.13 dB balance 0.61 alsactl -f /tmp/output store 0 iface MIXER name 'Front Playback Volume' value.0 33 value.1 79 range '0 - 87'
name 'Bass Speaker Playback Volume' value.0 87 value.1 87 range '0 - 87'
name 'Master Playback Volume' value 77 range '0 - 87'
name 'PCM Playback Volume' value.0 255 value.1 255 range '0 - 255'
You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with UCM.
Just install the latest pulseaudio (latest from repo), alsa-lib and alsa-ucm-conf (also from repo). If pulseaudio detects UCM, it has the preference.
Using the packages in debian unstable, `pacmd list` shows "use_ucm=yes". alsa-ucm-conf was already installed. Hopefully that's enough.
ii alsa-ucm-conf 1.2.1.2-2 all ALSA Use Case Manager configuration files ii libasound2:amd64 1.2.1.2-2 amd64 shared library for ALSA applications ii pulseaudio 13.0-5 amd64 PulseAudio sound server
pacmd list name: <module-alsa-card> argument: <device_id="0" name="pci-0000_00_1f.3" card_name="alsa_card.pci-0000_00_1f.3" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1">
Dne 11. 02. 20 v 12:42 Benjamin Poirier napsal(a):
On 2020/02/11 10:35 +0100, Jaroslav Kysela wrote:
Dne 11. 02. 20 v 9:16 Benjamin Poirier napsal(a):
[...]
Why PA handles the rear volume control with the current driver code in the legacy ALSA driver? It should be handled like standard stereo device. I'll check.
The device comes up with "Analog Stereo Output" profile by default. I changed it to "Analog Surround 4.0 Output" to test controlling each channel individually:
Yes, but does the volume control work (does PA change the appropriate ALSA mixer volume)? Sometimes, it's difficult to see the difference between soft volume attenuation and the hardware volume control.
I see what you mean. When set to the "Analog Surround 4.0 Output", pulseaudio didn't change the "Bass Speaker" mixer (always at 0dB gain). It used a combination of Master, Front and sometimes PCM mixers to control all four speakers.
Yes, that was the reason to keep only one volume control in the driver until we have a solution for this.
For example: pacmd list-sinks name: <alsa_output.pci-0000_00_1f.3.analog-surround-40> volume: front-left: 10349 / 16% / -48.09 dB, front-right: 39377 / 60% / -13.27 dB, rear-left: 23979 / 37% / -26.20 dB, rear-right: 47974 / 73% / -8.13 dB balance 0.61 alsactl -f /tmp/output store 0 iface MIXER name 'Front Playback Volume' value.0 33 value.1 79 range '0 - 87'
name 'Bass Speaker Playback Volume' value.0 87 value.1 87 range '0 - 87' name 'Master Playback Volume' value 77 range '0 - 87' name 'PCM Playback Volume' value.0 255 value.1 255 range '0 - 255'You should also test PA with UCM.
Please let me know what do I need to test exactly? I'm not familiar with UCM.
Just install the latest pulseaudio (latest from repo), alsa-lib and alsa-ucm-conf (also from repo). If pulseaudio detects UCM, it has the preference.
Using the packages in debian unstable, `pacmd list` shows "use_ucm=yes". alsa-ucm-conf was already installed. Hopefully that's enough.
ii alsa-ucm-conf 1.2.1.2-2 all ALSA Use Case Manager configuration files ii libasound2:amd64 1.2.1.2-2 amd64 shared library for ALSA applications ii pulseaudio 13.0-5 amd64 PulseAudio sound server
You should use the latest code. I will release ALSA packages version 1.2.2 soon, but PA must be latest (not yet released 14.0). Previous versions do not handle the volume control and HDMI jack detection. There are many UCM changes in 14.0.
Jaroslav
pacmd list name: <module-alsa-card> argument: <device_id="0" name="pci-0000_00_1f.3" card_name="alsa_card.pci-0000_00_1f.3" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1">
participants (4)
-
Benjamin Poirier -
Jaroslav Kysela -
Kailang -
Takashi Iwai