[PATCH 0/2] ALSA: hda/realtek: Add quirk for Minisforum V3 SE

[PATCH 0/2] ALSA: hda/realtek: Add quirk for Minisforum V3 SE

[Samuel Dionne-Riel]

Hi!

These changes fix audio for the Minisforum V3 SE.

While I didn't tag as RFC, as it might be just fine the way it is, I am
open to suggestions regarding how I implemented the first commit.

The main goal being it uses and exposes a generic name for this specific
fixup, while keeping to a minimal change. As mentioned in the commentary
for that patch, there are a couple other fixup functions that may aim at
applying the same fix, but it's hard to be sure without testing with the
original hardware this fixed.

There are more details about each change in their respective email, in
the commentary past the commit message.

Thank you for your time!

Samuel Dionne-Riel (2):
  ALSA: hda/realtek: Add generic quirk for Bass speaker DAC avoidance
  ALSA: hda/realtek: Add quirk for Minisforum V3 SE

 sound/hda/codecs/realtek/alc269.c | 8 ++++++++
 1 file changed, 8 insertions(+)


base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
-- 
2.51.0

[PATCH 1/2] ALSA: hda/realtek: Add generic quirk for Bass speaker DAC avoidance

[Samuel Dionne-Riel]

This change is for the follow-up commit, where the match on the specific
device (Minisforum V3 SE) is added.

This pattern (re-routing the bass speakers off of a DAC without volume
control) seems common enough that having a "model" to match against and
quickly use to verify may be worthwhile.

The alc285_fixup_thinkpad_x1_gen7 routing was selected, amongst the
different options, as it should allow tuning the ratio between both
speaker set.

The routing was verified using `hda-verb`, and picking either 0x00 or
0x01. Either routin made the volume of the bass speakers controllable.

    hda-verb /dev/snd/hwC1D0 0x17 SET_CONNECT_SEL 0x01

Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>

---

It may be worthwhile to clean-up behind and make the other fixups
re-routing `0x17` from `0x06` to either `0x02` or `0x03` also use the
same routing. It's a bit confusing, determining which routing to choose
when adding one for a device.

 - alc289_fixup_asus_ga401
 - alc295_fixup_disable_dac3

Might need to be checked (and re-used within a chain):

 - alc287_fixup_yoga9_14iap7_bass_spk_pin
 - alc245_fixup_hp_spectre_x360_eu0xxx
 - alc245_fixup_hp_spectre_x360_16_aa0xxx

I might be missing some, if for example they are handled through pin
fixups, or other fixup mechanisms.

I don't have the experience needed to know for sure if the cleanup would
be appropriate. So please excuse the lack of follow-up on that.

Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
---
 sound/hda/codecs/realtek/alc269.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index cafa48b5aceb5..5d38e371a6836 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3805,6 +3805,7 @@ enum {
 	ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED,
 	ALC288_FIXUP_SURFACE_SWAP_DACS,
 	ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO,
+	ALC245_FIXUP_BASS_HP_DAC,
 };
 
 /* A special fixup for Lenovo C940 and Yoga Duet 7;
@@ -6295,6 +6296,11 @@ static const struct hda_fixup alc269_fixups[] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc288_fixup_surface_swap_dacs,
 	},
+	[ALC245_FIXUP_BASS_HP_DAC] = {
+		.type = HDA_FIXUP_FUNC,
+		/* Borrow the DAC routing selected for those Thinkpads */
+		.v.func = alc285_fixup_thinkpad_x1_gen7,
+	},
 };
 
 static const struct hda_quirk alc269_fixup_tbl[] = {
@@ -7558,6 +7564,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
 	{.id = ALC285_FIXUP_HP_GPIO_AMP_INIT, .name = "alc285-hp-amp-init"},
 	{.id = ALC236_FIXUP_LENOVO_INV_DMIC, .name = "alc236-fixup-lenovo-inv-mic"},
 	{.id = ALC2XX_FIXUP_HEADSET_MIC, .name = "alc2xx-fixup-headset-mic"},
+	{.id = ALC245_FIXUP_BASS_HP_DAC, .name = "alc245-fixup-bass-hp-dac"},
 	{}
 };
 #define ALC225_STANDARD_PINS \
-- 
2.51.0

[PATCH 2/2] ALSA: hda/realtek: Add quirk for Minisforum V3 SE

[Samuel Dionne-Riel]

This likely will apply for the Minisforum V3, though there isn't a lot
of information to confirm whether or not the identifiers are the same.

The Minisforum V3 is likely to benefit from the same fix, as it exhibits
similar symptoms. Though users reportedly work around it by forcing the
software mixer.

This was verified on the Minisforum V3 SE, and the root cause (the bass
speakers routing) was found out by using pink noise, and playing with
the mixers.

Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>

---

For posterity, and hoping it helps someone else in the future, here's
the breadcrumbs I followed to get to this fix.

(Stopping other software, like Wireplumber, is needed here.)

The following command was used for the pink noise:

    speaker-test -Dhw:1,0 -c2

By using `alsamixer -c1`, muting either of the "Speaker" or "Bass
Speaker" channels showed that the speakers were indeed separate. On the
side of the device, there are two speaker grills next to each other, and
by moving an obstacle in front clearly shows the channels are
independent.

This differs from the “well-known” wisdom, where it is assumed the
speaker can't be controlled with the mixer. To be fair, software like
Wireplumber will mute the Bass Speaker in sync with the main Speaker,
which makes it seem like there is no control at all.

Knowing this fact, finding plausible fixes in the sound stack pointed at
the kernel driver being responsible for tying controls to the outputs.
And after fighting with some of the tooling, finding out that the
necessary knowledge is found in /proc/asound/card1/codec#0 in a quite
usable format unblocked me.

As a final hint, selecting an output using `hda-verb` uses the following
form:

   hda-verb /dev/snd/hwC1D0 $NODE SET_CONNECT_SEL $INDEX

Where `$NODE` is the node identifier found under
`/proc/asound/card1/codec#0`, and `$INDEX` is the index of the desired
DAC connection under `Connection:` in the same `/proc` file.

For my particular system, the `$NODE` is `0x17`, and the DAC can be
either `0` or `1`, as `0x06` is the DAC without volume control, and
`0x08` is an input.

    ~ $ cat /proc/asound/card1/codec#0 | grep -A15 '^Node 0x17'
    Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
      Control: name="Bass Speaker Playback Switch", index=0, device=0
        ControlAmp: chs=3, dir=Out, idx=0, ofs=0
      Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
      Amp-Out vals:  [0x80 0x80]
      Pincap 0x0000001c: OUT HP Detect
      Pin Default 0x90170120: [Fixed] Speaker at Int N/A
        Conn = Analog, Color = Unknown
        DefAssociation = 0x2, Sequence = 0x0
        Misc = NO_PRESENCE
      Pin-ctls: 0x40: OUT
      Unsolicited: tag=00, enabled=0
      Power states:  D0 D1 D2 D3 EPSS
      Power: setting=D0, actual=D0
      Connection: 4
         0x02 0x03 0x06* 0x08

    ~ $ cat /proc/asound/card1/codec#0 | grep '^Node 0x0[2368]'
    Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
    Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
    Node 0x06 [Audio Output] wcaps 0x411: Stereo
    Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In

Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
---
 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 5d38e371a6836..bcac3e9f106ca 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7370,6 +7370,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0xf111, 0x0009, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0xf111, 0x000b, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0xf111, 0x000c, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x1f4c, 0xe001, "Minisforum V3 (SE)", ALC245_FIXUP_BASS_HP_DAC),
 
 #if 0
 	/* Below is a quirk table taken from the old code.
-- 
2.51.0

Re: [PATCH 2/2] ALSA: hda/realtek: Add quirk for Minisforum V3 SE

[Takashi Iwai]

On Mon, 02 Feb 2026 00:12:15 +0100,
Samuel Dionne-Riel wrote:
> 
> This likely will apply for the Minisforum V3, though there isn't a lot
> of information to confirm whether or not the identifiers are the same.
> 
> The Minisforum V3 is likely to benefit from the same fix, as it exhibits
> similar symptoms. Though users reportedly work around it by forcing the
> software mixer.
> 
> This was verified on the Minisforum V3 SE, and the root cause (the bass
> speakers routing) was found out by using pink noise, and playing with
> the mixers.
> 
> Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
> 
> ---
> 
> For posterity, and hoping it helps someone else in the future, here's
> the breadcrumbs I followed to get to this fix.
> 
> (Stopping other software, like Wireplumber, is needed here.)
> 
> The following command was used for the pink noise:
> 
>     speaker-test -Dhw:1,0 -c2
> 
> By using `alsamixer -c1`, muting either of the "Speaker" or "Bass
> Speaker" channels showed that the speakers were indeed separate. On the
> side of the device, there are two speaker grills next to each other, and
> by moving an obstacle in front clearly shows the channels are
> independent.
> 
> This differs from the “well-known” wisdom, where it is assumed the
> speaker can't be controlled with the mixer. To be fair, software like
> Wireplumber will mute the Bass Speaker in sync with the main Speaker,
> which makes it seem like there is no control at all.
> 
> Knowing this fact, finding plausible fixes in the sound stack pointed at
> the kernel driver being responsible for tying controls to the outputs.
> And after fighting with some of the tooling, finding out that the
> necessary knowledge is found in /proc/asound/card1/codec#0 in a quite
> usable format unblocked me.
> 
> As a final hint, selecting an output using `hda-verb` uses the following
> form:
> 
>    hda-verb /dev/snd/hwC1D0 $NODE SET_CONNECT_SEL $INDEX
> 
> Where `$NODE` is the node identifier found under
> `/proc/asound/card1/codec#0`, and `$INDEX` is the index of the desired
> DAC connection under `Connection:` in the same `/proc` file.
> 
> For my particular system, the `$NODE` is `0x17`, and the DAC can be
> either `0` or `1`, as `0x06` is the DAC without volume control, and
> `0x08` is an input.
> 
>     ~ $ cat /proc/asound/card1/codec#0 | grep -A15 '^Node 0x17'
>     Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
>       Control: name="Bass Speaker Playback Switch", index=0, device=0
>         ControlAmp: chs=3, dir=Out, idx=0, ofs=0
>       Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>       Amp-Out vals:  [0x80 0x80]
>       Pincap 0x0000001c: OUT HP Detect
>       Pin Default 0x90170120: [Fixed] Speaker at Int N/A
>         Conn = Analog, Color = Unknown
>         DefAssociation = 0x2, Sequence = 0x0
>         Misc = NO_PRESENCE
>       Pin-ctls: 0x40: OUT
>       Unsolicited: tag=00, enabled=0
>       Power states:  D0 D1 D2 D3 EPSS
>       Power: setting=D0, actual=D0
>       Connection: 4
>          0x02 0x03 0x06* 0x08
> 
>     ~ $ cat /proc/asound/card1/codec#0 | grep '^Node 0x0[2368]'
>     Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
>     Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
>     Node 0x06 [Audio Output] wcaps 0x411: Stereo
>     Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In
> 
> Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
> ---
>  sound/hda/codecs/realtek/alc269.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
> index 5d38e371a6836..bcac3e9f106ca 100644
> --- a/sound/hda/codecs/realtek/alc269.c
> +++ b/sound/hda/codecs/realtek/alc269.c
> @@ -7370,6 +7370,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
>  	SND_PCI_QUIRK(0xf111, 0x0009, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
>  	SND_PCI_QUIRK(0xf111, 0x000b, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
>  	SND_PCI_QUIRK(0xf111, 0x000c, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
> +	SND_PCI_QUIRK(0x1f4c, 0xe001, "Minisforum V3 (SE)", ALC245_FIXUP_BASS_HP_DAC),

The table is sorted in PCI SSID order.  Please put at the appropriate
position.


thanks,

Takashi

Re: [PATCH 1/2] ALSA: hda/realtek: Add generic quirk for Bass speaker DAC avoidance

[Takashi Iwai]

On Mon, 02 Feb 2026 00:12:14 +0100,
Samuel Dionne-Riel wrote:
> 
> This change is for the follow-up commit, where the match on the specific
> device (Minisforum V3 SE) is added.
> 
> This pattern (re-routing the bass speakers off of a DAC without volume
> control) seems common enough that having a "model" to match against and
> quickly use to verify may be worthwhile.
> 
> The alc285_fixup_thinkpad_x1_gen7 routing was selected, amongst the
> different options, as it should allow tuning the ratio between both
> speaker set.
> 
> The routing was verified using `hda-verb`, and picking either 0x00 or
> 0x01. Either routin made the volume of the bass speakers controllable.
> 
>     hda-verb /dev/snd/hwC1D0 0x17 SET_CONNECT_SEL 0x01
> 
> Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
> 
> ---
> 
> It may be worthwhile to clean-up behind and make the other fixups
> re-routing `0x17` from `0x06` to either `0x02` or `0x03` also use the
> same routing. It's a bit confusing, determining which routing to choose
> when adding one for a device.
> 
>  - alc289_fixup_asus_ga401
>  - alc295_fixup_disable_dac3
> 
> Might need to be checked (and re-used within a chain):
> 
>  - alc287_fixup_yoga9_14iap7_bass_spk_pin
>  - alc245_fixup_hp_spectre_x360_eu0xxx
>  - alc245_fixup_hp_spectre_x360_16_aa0xxx
> 
> I might be missing some, if for example they are handled through pin
> fixups, or other fixup mechanisms.
> 
> I don't have the experience needed to know for sure if the cleanup would
> be appropriate. So please excuse the lack of follow-up on that.
> 
> Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>

Indeed it looks like that we can cleanup a lot regarding this DAC
routing fix-ups.  Though, *_thinkpad_x1_gen7() has more workarounds
about the control element renames -- which needs to be verified
whether the very same workaround is applicable to other cases.

IIUC, this kcontrol names (DAC1/DAC2) match with your device
configuration?  Could you give alsa-info.sh output?

In anyway, I don't think it's needed to split to two individual
commits.  You can fold into one patch.


thanks,

Takashi