Re: [alsa-devel] Constant noise on HDA ALC275
At Mon, 08 Oct 2012 14:46:24 +0200, Julien Danjou wrote:
[1 <multipart/mixed (7bit)>] [1.1 <text/plain (quoted-printable)>] On Mon, Oct 08 2012, Takashi Iwai wrote:
At best, please give alsa-info.sh outputs at both working and non-working cases. In that way, we can see the internal states more exactly than ambiguous descriptions.
Sure! Both attached.
The diff between background-noise and no-background-noise is:
--- /tmp/alsa-info-background-noise.txt 2012-10-08 14:41:05.880816525 +0200 +++ /tmp/alsa-info-no-background-noise.txt 2012-10-08 14:42:24.700814459 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 12:41:05 UTC 2012 +!!Script ran on: Mon Oct 8 12:42:24 UTC 2012
!!Linux Distribution @@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d
It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.)
Takashi
On Mon, Oct 08 2012, Takashi Iwai wrote:
It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.)
Yes, that's it.
(I just unloaded and reloaded the module and rechecked).
At Mon, 08 Oct 2012 14:57:23 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.)
Yes, that's it.
(I just unloaded and reloaded the module and rechecked).
OK, then could you try the patch below?
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8568aee..42dd605 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5988,10 +5988,22 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec, } }
+static void alc275_fixup_vaio_mixer(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + /* _UN_muting the input from NID 0x1d fixes the mysterious speaker + * noise on Sony VAIO Z + */ + if (action == ALC_FIXUP_ACT_INIT) + snd_hda_codec_write(codec, 0x0b, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_UNMUTE(4)); +}
enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, + ALC275_FIXUP_SONY_VAIO_MIXER, ALC269_FIXUP_DELL_M101Z, ALC269_FIXUP_SKU_IGNORE, ALC269_FIXUP_ASUS_G73JW, @@ -6031,6 +6043,12 @@ static const struct alc_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_SONY_VAIO }, + [ALC275_FIXUP_SONY_VAIO_MIXER] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc275_fixup_vaio_mixer, + .chained = true, + .chain_id = ALC269_FIXUP_SONY_VAIO + }, [ALC269_FIXUP_DELL_M101Z] = { .type = ALC_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { @@ -6172,6 +6190,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x104d, 0x9073, "Sony VAIO", ALC275_FIXUP_SONY_VAIO_GPIO2), SND_PCI_QUIRK(0x104d, 0x907b, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), SND_PCI_QUIRK(0x104d, 0x9084, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), + SND_PCI_QUIRK(0x104d, 0x90a5, "Sony VAIO Z", ALC275_FIXUP_SONY_VAIO_MIXER), SND_PCI_QUIRK_VENDOR(0x104d, "Sony VAIO", ALC269_FIXUP_SONY_VAIO), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z), SND_PCI_QUIRK_VENDOR(0x1025, "Acer Aspire", ALC271_FIXUP_DMIC),
On 10/08/2012 03:11 PM, Takashi Iwai wrote:
At Mon, 08 Oct 2012 14:57:23 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.)
Yes, that's it.
(I just unloaded and reloaded the module and rechecked).
OK, then could you try the patch below?
Takashi
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8568aee..42dd605 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5988,10 +5988,22 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec, } }
+static void alc275_fixup_vaio_mixer(struct hda_codec *codec,
const struct alc_fixup *fix, int action)+{
- /* _UN_muting the input from NID 0x1d fixes the mysterious speaker
* noise on Sony VAIO Z*/- if (action == ALC_FIXUP_ACT_INIT)
snd_hda_codec_write(codec, 0x0b, 0,AC_VERB_SET_AMP_GAIN_MUTE,AMP_IN_UNMUTE(4));+}
Hmm, isn't it easier just to toggle "Beep Playback Switch"?
At Mon, 08 Oct 2012 16:39:35 +0200, David Henningsson wrote:
On 10/08/2012 03:11 PM, Takashi Iwai wrote:
At Mon, 08 Oct 2012 14:57:23 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.)
Yes, that's it.
(I just unloaded and reloaded the module and rechecked).
OK, then could you try the patch below?
Takashi
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8568aee..42dd605 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5988,10 +5988,22 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec, } }
+static void alc275_fixup_vaio_mixer(struct hda_codec *codec,
const struct alc_fixup *fix, int action)+{
- /* _UN_muting the input from NID 0x1d fixes the mysterious speaker
* noise on Sony VAIO Z*/- if (action == ALC_FIXUP_ACT_INIT)
snd_hda_codec_write(codec, 0x0b, 0,AC_VERB_SET_AMP_GAIN_MUTE,AMP_IN_UNMUTE(4));+}
Hmm, isn't it easier just to toggle "Beep Playback Switch"?
Good point. I'm actually not sure whether the 0x1d is supposed to be beep on ALC275 as well. It's been so for ALC269, but ALC275 might be different.
Takashi
At Mon, 08 Oct 2012 17:07:44 +0200, Takashi Iwai wrote:
At Mon, 08 Oct 2012 16:39:35 +0200, David Henningsson wrote:
On 10/08/2012 03:11 PM, Takashi Iwai wrote:
At Mon, 08 Oct 2012 14:57:23 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.)
Yes, that's it.
(I just unloaded and reloaded the module and rechecked).
OK, then could you try the patch below?
Takashi
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8568aee..42dd605 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5988,10 +5988,22 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec, } }
+static void alc275_fixup_vaio_mixer(struct hda_codec *codec,
const struct alc_fixup *fix, int action)+{
- /* _UN_muting the input from NID 0x1d fixes the mysterious speaker
* noise on Sony VAIO Z*/- if (action == ALC_FIXUP_ACT_INIT)
snd_hda_codec_write(codec, 0x0b, 0,AC_VERB_SET_AMP_GAIN_MUTE,AMP_IN_UNMUTE(4));+}
Hmm, isn't it easier just to toggle "Beep Playback Switch"?
Good point. I'm actually not sure whether the 0x1d is supposed to be beep on ALC275 as well. It's been so for ALC269, but ALC275 might be different.
In other words: Julien, could you check whether beep volume from speaker/headphone changes when you adjust "Beep" volume in alsa mixer?
Takashi
On Mon, Oct 08 2012, Takashi Iwai wrote:
In other words: Julien, could you check whether beep volume from speaker/headphone changes when you adjust "Beep" volume in alsa mixer?
When you say beep volume from speaker/headphone, do you refer to what I call noise?
Because if yes, this is actually the case:
- if "Beep" muted -> noise :( - if "Beep" unmuted and volume == 0 -> no noise :) - if "Beep" unmuted and volume > 0 -> different type of noises! :(
At Mon, 08 Oct 2012 17:41:02 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
In other words: Julien, could you check whether beep volume from speaker/headphone changes when you adjust "Beep" volume in alsa mixer?
When you say beep volume from speaker/headphone, do you refer to what I call noise?
No, not about noise but the system beep sound. Such like % echo -en "\a" on Linux console.
Takashi
Because if yes, this is actually the case:
- if "Beep" muted -> noise :(
- if "Beep" unmuted and volume == 0 -> no noise :)
- if "Beep" unmuted and volume > 0 -> different type of noises! :(
-- Julien Danjou -- Free Software hacker & freelance -- http://julien.danjou.info [2 <application/pgp-signature (7bit)>]
On Mon, Oct 08 2012, Takashi Iwai wrote:
No, not about noise but the system beep sound. Such like % echo -en "\a" on Linux console.
Oh that. Yes, the volume I hear when echoing a '\a' change correctly when I change the beep volume in alsamixer.
(On a side note, I don't know how precise it should be, but setting the beep volume to 0 (but still unmuted) still does an audible beep.)
At Mon, 08 Oct 2012 18:09:10 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
No, not about noise but the system beep sound. Such like % echo -en "\a" on Linux console.
Oh that. Yes, the volume I hear when echoing a '\a' change correctly when I change the beep volume in alsamixer.
Thanks, it's good to know. So the current implementation of beep control itself is OK. The rest is to stop the mixer amp mute via Beep switch...
(On a side note, I don't know how precise it should be, but setting the beep volume to 0 (but still unmuted) still does an audible beep.)
It's normal behavior on many codecs. The lowest volume level doesn't mean the mute state.
Takashi
On Mon, Oct 08 2012, Takashi Iwai wrote:
OK, then could you try the patch below?
The patch is not enough on itself, but it seems on a good track. As soon as the module is started, the noise starts for one second and stops.
The "Beep Playback Switch" is shown as muted in alsamixer. If I unmute it, well, no noise, as expected. If i re-mute it, the noise come back.
So this patch just works after module loading, but I guess that's to be expected if I understand the code correctly. :)
At Mon, 08 Oct 2012 18:24:23 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
OK, then could you try the patch below?
The patch is not enough on itself, but it seems on a good track. As soon as the module is started, the noise starts for one second and stops.
The "Beep Playback Switch" is shown as muted in alsamixer. If I unmute it, well, no noise, as expected. If i re-mute it, the noise come back.
So this patch just works after module loading, but I guess that's to be expected if I understand the code correctly. :)
Yep, as David pointed out, the beep control overrides the amp setup. And your previous result suggested that we shouldn't use this beep path either (except for unmuting it), otherwise you get a noise again.
So, the patch below is the revised version. It removes the beep control but still opens the path to NID 0x1d.
Let me know if this works better.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8568aee..1cf45d0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4249,6 +4249,7 @@ static const struct snd_pci_quirk beep_white_list[] = { SND_PCI_QUIRK(0x1043, 0x83ce, "EeePC", 1), SND_PCI_QUIRK(0x1043, 0x831a, "EeePC", 1), SND_PCI_QUIRK(0x1043, 0x834a, "EeePC", 1), + SND_PCI_QUIRK(0x104d, 0x90a5, "Sony VAIO Z", 0), /* beep cause noise */ SND_PCI_QUIRK(0x1458, 0xa002, "GA-MA790X", 1), SND_PCI_QUIRK(0x8086, 0xd613, "Intel", 1), {} @@ -5988,10 +5989,22 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec, } }
+static void alc275_fixup_vaio_mixer(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + /* _UN_muting the input from NID 0x1d fixes the mysterious speaker + * noise on Sony VAIO Z + */ + if (action == ALC_FIXUP_ACT_INIT) + snd_hda_codec_write(codec, 0x0b, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AMP_IN_UNMUTE(4)); +}
enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, + ALC275_FIXUP_SONY_VAIO_MIXER, ALC269_FIXUP_DELL_M101Z, ALC269_FIXUP_SKU_IGNORE, ALC269_FIXUP_ASUS_G73JW, @@ -6031,6 +6044,12 @@ static const struct alc_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_SONY_VAIO }, + [ALC275_FIXUP_SONY_VAIO_MIXER] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc275_fixup_vaio_mixer, + .chained = true, + .chain_id = ALC269_FIXUP_SONY_VAIO + }, [ALC269_FIXUP_DELL_M101Z] = { .type = ALC_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { @@ -6172,6 +6191,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x104d, 0x9073, "Sony VAIO", ALC275_FIXUP_SONY_VAIO_GPIO2), SND_PCI_QUIRK(0x104d, 0x907b, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), SND_PCI_QUIRK(0x104d, 0x9084, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), + SND_PCI_QUIRK(0x104d, 0x90a5, "Sony VAIO Z", ALC275_FIXUP_SONY_VAIO_MIXER), SND_PCI_QUIRK_VENDOR(0x104d, "Sony VAIO", ALC269_FIXUP_SONY_VAIO), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z), SND_PCI_QUIRK_VENDOR(0x1025, "Acer Aspire", ALC271_FIXUP_DMIC),
On Mon, Oct 08 2012, Takashi Iwai wrote:
Yep, as David pointed out, the beep control overrides the amp setup. And your previous result suggested that we shouldn't use this beep path either (except for unmuting it), otherwise you get a noise again.
So, the patch below is the revised version. It removes the beep control but still opens the path to NID 0x1d.
It does remove the beep control, and I think it therefore break the beep functionnality: I've no sound when echoing '\a'. But that's likely to be expected anyhow. :-/
But yeah, definitely, I've no noise anymore in this case with this patch.
Now, I can still make the noise come back when "speaker" or "master" is muted. This is definitely not a side effect of your patch, I just didn't raise it before.
This diff is between "no noise" (= just loaded the module with your patch) and "noise with master muted":
diff -u /tmp/no-noise.txt /tmp/noise-master-mute.txt --- /tmp/no-noise.txt 2012-10-08 18:36:44.601047347 +0200 +++ /tmp/noise-master-mute.txt 2012-10-08 18:37:02.221050163 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 16:36:44 UTC 2012 +!!Script ran on: Mon Oct 8 16:37:02 UTC 2012
!!Linux Distribution @@ -260,7 +260,7 @@ ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 - Amp-Out vals: [0x00 0x00] + Amp-Out vals: [0x80 0x80] Pincap 0x00010050: OUT EAPD Balanced EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A
This diff is between "no noise" (= just loaded the module with your patch) and "noise with speaker muted":
diff -u /tmp/no-noise.txt /tmp/noise-speaker-mute.txt --- /tmp/no-noise.txt 2012-10-08 18:36:44.601047347 +0200 +++ /tmp/noise-speaker-mute.txt 2012-10-08 18:37:10.913051519 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 16:36:44 UTC 2012 +!!Script ran on: Mon Oct 8 16:37:10 UTC 2012
!!Linux Distribution @@ -260,7 +260,7 @@ ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 - Amp-Out vals: [0x00 0x00] + Amp-Out vals: [0x80 0x80] Pincap 0x00010050: OUT EAPD Balanced EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A
Now, I've discovered one more thing, don't know if you know. This is how I managed to REALLY mute the speakers, the noise, everything (even playing a sound file with everything unmuted makes no sound):
% diff -u /tmp/sound.txt /tmp/no-sound-at-all.txt --- /tmp/sound.txt 2012-10-08 18:48:02.605161041 +0200 +++ /tmp/no-sound-at-all.txt 2012-10-08 18:47:50.453158964 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 16:48:02 UTC 2012 +!!Script ran on: Mon Oct 8 16:47:50 UTC 2012
!!Linux Distribution @@ -267,7 +267,7 @@ Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE - Pin-ctls: 0x40: OUT + Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2
When doing that, I cannot hear anything, because it seems to disconnect the speakers. My idea would be to set this pin to 0x00 instead of 0x40 when "Speakers" are set to mute (I don't know about master though). WDYT?
Attached all the files.
This sound card seems really weird. :)
At Mon, 08 Oct 2012 18:52:26 +0200, Julien Danjou wrote:
On Mon, Oct 08 2012, Takashi Iwai wrote:
Yep, as David pointed out, the beep control overrides the amp setup. And your previous result suggested that we shouldn't use this beep path either (except for unmuting it), otherwise you get a noise again.
So, the patch below is the revised version. It removes the beep control but still opens the path to NID 0x1d.
It does remove the beep control, and I think it therefore break the beep functionnality: I've no sound when echoing '\a'. But that's likely to be expected anyhow. :-/
Doesn't the beep work if you load pcspkr module? It should be there independently.
But yeah, definitely, I've no noise anymore in this case with this patch.
Now, I can still make the noise come back when "speaker" or "master" is muted. This is definitely not a side effect of your patch, I just didn't raise it before.
Hm, then maybe the effect of removing noise appears no matter which input of NID 0x0b be unmuted?
This diff is between "no noise" (= just loaded the module with your patch) and "noise with master muted":
diff -u /tmp/no-noise.txt /tmp/noise-master-mute.txt --- /tmp/no-noise.txt 2012-10-08 18:36:44.601047347 +0200 +++ /tmp/noise-master-mute.txt 2012-10-08 18:37:02.221050163 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 16:36:44 UTC 2012 +!!Script ran on: Mon Oct 8 16:37:02 UTC 2012
!!Linux Distribution @@ -260,7 +260,7 @@ ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
- Amp-Out vals: [0x00 0x00]
- Amp-Out vals: [0x80 0x80] Pincap 0x00010050: OUT EAPD Balanced EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A
This diff is between "no noise" (= just loaded the module with your patch) and "noise with speaker muted":
diff -u /tmp/no-noise.txt /tmp/noise-speaker-mute.txt --- /tmp/no-noise.txt 2012-10-08 18:36:44.601047347 +0200 +++ /tmp/noise-speaker-mute.txt 2012-10-08 18:37:10.913051519 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 16:36:44 UTC 2012 +!!Script ran on: Mon Oct 8 16:37:10 UTC 2012
!!Linux Distribution @@ -260,7 +260,7 @@ ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
- Amp-Out vals: [0x00 0x00]
- Amp-Out vals: [0x80 0x80] Pincap 0x00010050: OUT EAPD Balanced EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A
So, obviously muting the amp triggers the noise. BTW, does the noise come only from speaker, not from headphone, correct?
Related tests: what happens if you mute both input amps of the node 0x0d? This is a mixer widget between DAC and the speaker pin. Does this widget work as a proper mute/unmute point without causing noise?
Now, I've discovered one more thing, don't know if you know. This is how I managed to REALLY mute the speakers, the noise, everything (even playing a sound file with everything unmuted makes no sound):
% diff -u /tmp/sound.txt /tmp/no-sound-at-all.txt --- /tmp/sound.txt 2012-10-08 18:48:02.605161041 +0200 +++ /tmp/no-sound-at-all.txt 2012-10-08 18:47:50.453158964 +0200 @@ -3,7 +3,7 @@ !!ALSA Information Script v 0.4.61 !!################################
-!!Script ran on: Mon Oct 8 16:48:02 UTC 2012 +!!Script ran on: Mon Oct 8 16:47:50 UTC 2012
!!Linux Distribution @@ -267,7 +267,7 @@ Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE
- Pin-ctls: 0x40: OUT
- Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2
This essentially disables the output of the speaker pin.
When doing that, I cannot hear anything, because it seems to disconnect the speakers. My idea would be to set this pin to 0x00 instead of 0x40 when "Speakers" are set to mute (I don't know about master though). WDYT?
Possible, but a bit hackish. Let's see...
Takashi
On Mon, Oct 08 2012, Takashi Iwai wrote:
Doesn't the beep work if you load pcspkr module? It should be there independently.
pcspkr is loaded, but no sound from the speakers. And I don't think this laptop has an old buzzer. ;)
Hm, then maybe the effect of removing noise appears no matter which input of NID 0x0b be unmuted?
I've retested some, and you're right, it seems some others do make the noise disappear:
For example, this works too:
@@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 - Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] + Amp-In vals: [0x80 0x80] [0x80 0x80] [0x00 0x00] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
This one too: @@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 - Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] + Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Other pairs do not work, but some do change the noise sound.
No pair work when speakers or master is muted; the noise is always there, no matter which pair I mute/unmute.
So, obviously muting the amp triggers the noise. BTW, does the noise come only from speaker, not from headphone, correct?
Yeah correct. Never got any noise in the headphone. (That's how and why I didn't got insane so far with that noise always there :)
Related tests: what happens if you mute both input amps of the node 0x0d? This is a mixer widget between DAC and the speaker pin. Does this widget work as a proper mute/unmute point without causing noise?
I tried all combinations on 0x0d with master unmuted: there's 2 inputs, so 4 combinations, and I got… 4 different noises. Almost funny. If master is muted, changing any input amps from 0x0d change nothing at all, noise still there.
When doing that, I cannot hear anything, because it seems to disconnect the speakers. My idea would be to set this pin to 0x00 instead of 0x40 when "Speakers" are set to mute (I don't know about master though). WDYT?
Possible, but a bit hackish. Let's see...
Heh, too bad. But you know better than me. :)
On 10/08/2012 10:34 PM, Julien Danjou wrote:
Hm, then maybe the effect of removing noise appears no matter which input of NID 0x0b be unmuted?
I've retested some, and you're right, it seems some others do make the noise disappear:
For example, this works too:
@@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x00 0x00] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
This one too: @@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Other pairs do not work, but some do change the noise sound.
So; if everything is muted, it causes some codec bug to appear. If this only happens in the speaker, maybe we should try to reroute the speaker to go 0x02 -> 0x0c -> 0x14 instead of 0x03 -> 0x0d -> 0x14? What will happen if you change 0x14 to take its input from 0x0c instead?
At Tue, 09 Oct 2012 08:19:56 +0200, David Henningsson wrote:
On 10/08/2012 10:34 PM, Julien Danjou wrote:
Hm, then maybe the effect of removing noise appears no matter which input of NID 0x0b be unmuted?
I've retested some, and you're right, it seems some others do make the noise disappear:
For example, this works too:
@@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x00 0x00] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
This one too: @@ -198,7 +198,7 @@ Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
- Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Other pairs do not work, but some do change the noise sound.
So; if everything is muted, it causes some codec bug to appear. If this only happens in the speaker, maybe we should try to reroute the speaker to go 0x02 -> 0x0c -> 0x14 instead of 0x03 -> 0x0d -> 0x14? What will happen if you change 0x14 to take its input from 0x0c instead?
Your suggestion reminds me of another bug on another Vaio Z model but with a different codec. On that machine, the speaker output must come from the first DAC. Otherwise silences. Julien's machine might have a similar restriction.
The patch below will change the DAC assignment order. Give it a try instead of previous ones.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 8568aee..838b6e7 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5992,6 +5992,7 @@ static void alc269_fixup_mic2_mute(struct hda_codec *codec, enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, + ALC275_FIXUP_VAIO_SPEAKER, ALC269_FIXUP_DELL_M101Z, ALC269_FIXUP_SKU_IGNORE, ALC269_FIXUP_ASUS_G73JW, @@ -6031,6 +6032,12 @@ static const struct alc_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_SONY_VAIO }, + [ALC275_FIXUP_VAIO_SPEAKER] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc882_fixup_no_primary_hp, /* same quirk code */ + .chained = true, + .chain_id = ALC269_FIXUP_SONY_VAIO + }, [ALC269_FIXUP_DELL_M101Z] = { .type = ALC_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { @@ -6172,6 +6179,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x104d, 0x9073, "Sony VAIO", ALC275_FIXUP_SONY_VAIO_GPIO2), SND_PCI_QUIRK(0x104d, 0x907b, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), SND_PCI_QUIRK(0x104d, 0x9084, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), + SND_PCI_QUIRK(0x104d, 0x90a5, "Sony VAIO Z", ALC275_FIXUP_VAIO_SPEAKER), SND_PCI_QUIRK_VENDOR(0x104d, "Sony VAIO", ALC269_FIXUP_SONY_VAIO), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z), SND_PCI_QUIRK_VENDOR(0x1025, "Acer Aspire", ALC271_FIXUP_DMIC),
On Tue, Oct 09 2012, Takashi Iwai wrote:
Your suggestion reminds me of another bug on another Vaio Z model but with a different codec. On that machine, the speaker output must come from the first DAC. Otherwise silences. Julien's machine might have a similar restriction.
The patch below will change the DAC assignment order. Give it a try instead of previous ones.
Unfortunately, this doesn't help at all: with that patch I've a bunch of different noises following what I mute/unmute. And muting/unmuting the "Beep" toggles a different noise, but I cannot find the silence back. :(
On Tue, Oct 09 2012, David Henningsson wrote:
Hi David, Takashi,
I'm still trying to advance on this! :)
So; if everything is muted, it causes some codec bug to appear. If this only happens in the speaker, maybe we should try to reroute the speaker to go 0x02 -> 0x0c -> 0x14 instead of 0x03 -> 0x0d -> 0x14? What will happen if you change 0x14 to take its input from 0x0c instead?
I just did that using the hda-analyzer tool. I changed 0x14 to uses 0x0c as a source, and it's indeed much better. The noise disappear when neither master or speaker is muted, and actually the music playback sounds better and without the little background noise I still hear on low volume level.
Actually, I'm sure it'd be easy to come with a patch, so my question would rather be: what's this routing about, and why is 0x0d set up instead of 0x0c?
I'm still trying to find a way to fix the noise when speaker or master are muted. No chance so far. :(
At Thu, 01 Nov 2012 23:39:52 +0100, Julien Danjou wrote:
On Tue, Oct 09 2012, David Henningsson wrote:
Hi David, Takashi,
I'm still trying to advance on this! :)
So; if everything is muted, it causes some codec bug to appear. If this only happens in the speaker, maybe we should try to reroute the speaker to go 0x02 -> 0x0c -> 0x14 instead of 0x03 -> 0x0d -> 0x14? What will happen if you change 0x14 to take its input from 0x0c instead?
I just did that using the hda-analyzer tool. I changed 0x14 to uses 0x0c as a source, and it's indeed much better. The noise disappear when neither master or speaker is muted, and actually the music playback sounds better and without the little background noise I still hear on low volume level.
Good to hear. What's the remaining issue?
Actually, I'm sure it'd be easy to come with a patch, so my question would rather be: what's this routing about, and why is 0x0d set up instead of 0x0c?
The current parser prefers the line-out as the primary output over the headphone. Then it tries to assign from the smaller NID, so 0x0c is assigned to the line-out (which is the speaker in your case), then 0x0d is to the headphone.
I'm still trying to find a way to fix the noise when speaker or master are muted. No chance so far. :(
Do you mean that the noise is there with rerouting like the above, or you are asking for a patch to achieve the rerouting?
Takashi
On Fri, Nov 02 2012, Takashi Iwai wrote:
I just did that using the hda-analyzer tool. I changed 0x14 to uses 0x0c as a source, and it's indeed much better. The noise disappear when neither master or speaker is muted, and actually the music playback sounds better and without the little background noise I still hear on low volume level.
Good to hear. What's the remaining issue?
Well, it's still not perfect, and as I wrote, if any of "master" or "speaker" is muted, the noise kicks back in instantly. :(
The current parser prefers the line-out as the primary output over the headphone. Then it tries to assign from the smaller NID, so 0x0c is assigned to the line-out (which is the speaker in your case), then 0x0d is to the headphone.
Ok, thanks for the explanation.
I'm still trying to find a way to fix the noise when speaker or master are muted. No chance so far. :(
Do you mean that the noise is there with rerouting like the above, or you are asking for a patch to achieve the rerouting?
If "master" or "speaker" is muted, the noise kicks back in, whatever the routing is.
At this point, I wonder if it wouldn't be simpler to just boot the machine under Windows and dump the HDA state to see how the Windows driver set up all the routing. Do you think this kind of approach would work, and in that case, is there a tool do achieve that?
At Fri, 02 Nov 2012 12:29:40 +0100, Julien Danjou wrote:
On Fri, Nov 02 2012, Takashi Iwai wrote:
I just did that using the hda-analyzer tool. I changed 0x14 to uses 0x0c as a source, and it's indeed much better. The noise disappear when neither master or speaker is muted, and actually the music playback sounds better and without the little background noise I still hear on low volume level.
Good to hear. What's the remaining issue?
Well, it's still not perfect, and as I wrote, if any of "master" or "speaker" is muted, the noise kicks back in instantly. :(
OK, the behavior wasn't clear in your text above, so I asked it again. (mute and unmute are pretty confusing :)
The current parser prefers the line-out as the primary output over the headphone. Then it tries to assign from the smaller NID, so 0x0c is assigned to the line-out (which is the speaker in your case), then 0x0d is to the headphone.
Ok, thanks for the explanation.
I'm still trying to find a way to fix the noise when speaker or master are muted. No chance so far. :(
Do you mean that the noise is there with rerouting like the above, or you are asking for a patch to achieve the rerouting?
If "master" or "speaker" is muted, the noise kicks back in, whatever the routing is.
At this point, I wonder if it wouldn't be simpler to just boot the machine under Windows and dump the HDA state to see how the Windows driver set up all the routing. Do you think this kind of approach would work, and in that case, is there a tool do achieve that?
I have no idea about Windows, sorry.
Takashi
participants (3)
-
David Henningsson -
Julien Danjou -
Takashi Iwai