[PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892

[PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892

[Thierry Reding]

Unmuting the analog bypass causes any input to be directly bypassed to
the outputs, which is usually not expected by the user.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
Note that this patch could be generalized to include all codec variants
that have this second channel. As I don't have access to all the data
sheets I'll leave that decision up to somebody with more hardware
available.

 sound/pci/hda/patch_realtek.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4f81dd4..54d0917 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3752,8 +3752,15 @@ static void alc_auto_set_output_and_unmute(struct hda_codec *codec,
 	if (nid_has_mute(codec, mix, HDA_INPUT)) {
 		snd_hda_codec_write(codec, mix, 0, AC_VERB_SET_AMP_GAIN_MUTE,
 			    AMP_IN_UNMUTE(0));
-		snd_hda_codec_write(codec, mix, 0, AC_VERB_SET_AMP_GAIN_MUTE,
-			    AMP_IN_UNMUTE(1));
+		/*
+		 * On ALC892, the second entry in the connection list is the
+		 * analog bypass. Unmuting it will cause any inputs to be
+		 * directly forwarded to the corresponding outputs.
+		 */
+		if (codec->subsystem_id != 0x10ec0892)
+			snd_hda_codec_write(codec, mix, 0,
+					    AC_VERB_SET_AMP_GAIN_MUTE,
+					    AMP_IN_UNMUTE(1));
 	}
 	/* initialize volume */
 	nid = alc_look_for_out_vol_nid(codec, pin, dac);
-- 
1.7.11.4

Re: [PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892

[Takashi Iwai]

At Thu,  9 Aug 2012 08:47:19 +0200,
Thierry Reding wrote:
> 
> Unmuting the analog bypass causes any input to be directly bypassed to
> the outputs, which is usually not expected by the user.
> 
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---
> Note that this patch could be generalized to include all codec variants
> that have this second channel. As I don't have access to all the data
> sheets I'll leave that decision up to somebody with more hardware
> available.

Hmm, are you really sure that this is exclusive switch between two?
All Realtek codecs with this mixer widget mixes two sources up.
Otherwise it must not be a "mixer" widget at all but it must be a
"selector" widget.

And I haven't received a bug report regarding this although ALC892 is
no new chip and the auto-parser has been enabled for so long time.


thanks,

Takashi


> 
>  sound/pci/hda/patch_realtek.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 4f81dd4..54d0917 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -3752,8 +3752,15 @@ static void alc_auto_set_output_and_unmute(struct hda_codec *codec,
>  	if (nid_has_mute(codec, mix, HDA_INPUT)) {
>  		snd_hda_codec_write(codec, mix, 0, AC_VERB_SET_AMP_GAIN_MUTE,
>  			    AMP_IN_UNMUTE(0));
> -		snd_hda_codec_write(codec, mix, 0, AC_VERB_SET_AMP_GAIN_MUTE,
> -			    AMP_IN_UNMUTE(1));
> +		/*
> +		 * On ALC892, the second entry in the connection list is the
> +		 * analog bypass. Unmuting it will cause any inputs to be
> +		 * directly forwarded to the corresponding outputs.
> +		 */
> +		if (codec->subsystem_id != 0x10ec0892)
> +			snd_hda_codec_write(codec, mix, 0,
> +					    AC_VERB_SET_AMP_GAIN_MUTE,
> +					    AMP_IN_UNMUTE(1));
>  	}
>  	/* initialize volume */
>  	nid = alc_look_for_out_vol_nid(codec, pin, dac);
> -- 
> 1.7.11.4
> 

Re: [PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Thu, Aug 09, 2012 at 09:02:10AM +0200, Takashi Iwai wrote:
> At Thu,  9 Aug 2012 08:47:19 +0200,
> Thierry Reding wrote:
> > 
> > Unmuting the analog bypass causes any input to be directly bypassed to
> > the outputs, which is usually not expected by the user.
> > 
> > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> > ---
> > Note that this patch could be generalized to include all codec variants
> > that have this second channel. As I don't have access to all the data
> > sheets I'll leave that decision up to somebody with more hardware
> > available.
> 
> Hmm, are you really sure that this is exclusive switch between two?
> All Realtek codecs with this mixer widget mixes two sources up.
> Otherwise it must not be a "mixer" widget at all but it must be a
> "selector" widget.

It's not an exclusive switch. But the second input is the analog bypass
that basically takes the signal directly from the input path and routes
it to the output.

> And I haven't received a bug report regarding this although ALC892 is
> no new chip and the auto-parser has been enabled for so long time.

I've seen this happen when feeding a signal into the CD-IN (NID 0x1c),
which is then directly routed to the output, so I actually hear that
signal at the output, even if there is no software loopback to capture
the input and play it back via the DAC.

This is probably not a very common use-case, so maybe nobody else has
come across it. Looking at the block diagram in the ALC892 datasheet
(page 5) clearly shows where the input of this second switch comes from.
I don't think this is intended to be unmuted by default, but only in
very special cases where you actually want to pass the analog input
signal directly to the output without going through the ADC and back out
the DAC.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892

[Takashi Iwai]

At Thu, 9 Aug 2012 09:18:48 +0200,
Thierry Reding wrote:
> 
> On Thu, Aug 09, 2012 at 09:02:10AM +0200, Takashi Iwai wrote:
> > At Thu,  9 Aug 2012 08:47:19 +0200,
> > Thierry Reding wrote:
> > > 
> > > Unmuting the analog bypass causes any input to be directly bypassed to
> > > the outputs, which is usually not expected by the user.
> > > 
> > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> > > ---
> > > Note that this patch could be generalized to include all codec variants
> > > that have this second channel. As I don't have access to all the data
> > > sheets I'll leave that decision up to somebody with more hardware
> > > available.
> > 
> > Hmm, are you really sure that this is exclusive switch between two?
> > All Realtek codecs with this mixer widget mixes two sources up.
> > Otherwise it must not be a "mixer" widget at all but it must be a
> > "selector" widget.
> 
> It's not an exclusive switch. But the second input is the analog bypass
> that basically takes the signal directly from the input path and routes
> it to the output.

Ah so you mean it as the analog loopback path.
Normal users even want this often.

> > And I haven't received a bug report regarding this although ALC892 is
> > no new chip and the auto-parser has been enabled for so long time.
> 
> I've seen this happen when feeding a signal into the CD-IN (NID 0x1c),
> which is then directly routed to the output, so I actually hear that
> signal at the output, even if there is no software loopback to capture
> the input and play it back via the DAC.
> 
> This is probably not a very common use-case, so maybe nobody else has
> come across it. Looking at the block diagram in the ALC892 datasheet
> (page 5) clearly shows where the input of this second switch comes from.
> I don't think this is intended to be unmuted by default, but only in
> very special cases where you actually want to pass the analog input
> signal directly to the output without going through the ADC and back out
> the DAC.

Each input has the analog loopback mixer switch (and off as default).
Why it doesn't suffice?


thanks,

Takashi

Re: [PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]

On Thu, Aug 09, 2012 at 09:33:43AM +0200, Takashi Iwai wrote:
> At Thu, 9 Aug 2012 09:18:48 +0200,
> Thierry Reding wrote:
> > 
> > On Thu, Aug 09, 2012 at 09:02:10AM +0200, Takashi Iwai wrote:
> > > At Thu,  9 Aug 2012 08:47:19 +0200,
> > > Thierry Reding wrote:
> > > > 
> > > > Unmuting the analog bypass causes any input to be directly bypassed to
> > > > the outputs, which is usually not expected by the user.
> > > > 
> > > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> > > > ---
> > > > Note that this patch could be generalized to include all codec variants
> > > > that have this second channel. As I don't have access to all the data
> > > > sheets I'll leave that decision up to somebody with more hardware
> > > > available.
> > > 
> > > Hmm, are you really sure that this is exclusive switch between two?
> > > All Realtek codecs with this mixer widget mixes two sources up.
> > > Otherwise it must not be a "mixer" widget at all but it must be a
> > > "selector" widget.
> > 
> > It's not an exclusive switch. But the second input is the analog bypass
> > that basically takes the signal directly from the input path and routes
> > it to the output.
> 
> Ah so you mean it as the analog loopback path.

Yes.

> > > And I haven't received a bug report regarding this although ALC892 is
> > > no new chip and the auto-parser has been enabled for so long time.
> > 
> > I've seen this happen when feeding a signal into the CD-IN (NID 0x1c),
> > which is then directly routed to the output, so I actually hear that
> > signal at the output, even if there is no software loopback to capture
> > the input and play it back via the DAC.
> > 
> > This is probably not a very common use-case, so maybe nobody else has
> > come across it. Looking at the block diagram in the ALC892 datasheet
> > (page 5) clearly shows where the input of this second switch comes from.
> > I don't think this is intended to be unmuted by default, but only in
> > very special cases where you actually want to pass the analog input
> > signal directly to the output without going through the ADC and back out
> > the DAC.
> 
> Each input has the analog loopback mixer switch (and off as default).
> Why it doesn't suffice?

I hadn't thought about that. I'll need to recheck if that solves the
issue that I was seeing.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]