[alsa-devel] [PATCH] ALSA: hda/realtek - Keep analog bypass muted on ALC892
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);
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,
} /* initialize volume */ nid = alc_look_for_out_vol_nid(codec, pin, dac);AMP_IN_UNMUTE(1));
-- 1.7.11.4
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
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
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
participants (2)
-
Takashi Iwai
-
Thierry Reding