Re: [alsa-devel] 2.6.29 regression: left audio channel broken after resume from suspend with Intel HDA
At Tue, 21 Apr 2009 20:39:36 +0200, Tino Keitel wrote:
On Tue, Apr 21, 2009 at 09:39:13 +0200, Takashi Iwai wrote:
At Tue, 21 Apr 2009 09:32:19 +0200, Tino Keitel wrote:
On Tue, Apr 21, 2009 at 07:24:40 +0200, Takashi Iwai wrote:
The commit is fcad94a4c71c36a05f4d5c6dcb174534b4e0b136: ALSA: hda - Fix the cmd cache keys for amp verbs
Thanks for the reply. However, the patch doesn't work. I just got distorted sound again.
Then please run alsa-info.sh (with --no-upload option) before and after suspend, and attach the generated files. Also, check the latest Linus tree whether the problem still appears.
My first impression with suspend seems to be wrong. It also sometimes happens just after a while, event without suspend.
Attached are 2 alsa-info.sh outputs. One was taken after I noticed the distorted sound, one after I reloaded snd-hda-intel to fix the distortion. The mixer seems to be quite different after module reload.
The codec communication looks a bit unstable on this device... Does this still happen on the latest 2.6.30 version?
Takashi
On Fri, Apr 24, 2009 at 16:01:40 +0200, Takashi Iwai wrote:
[...]
The codec communication looks a bit unstable on this device... Does this still happen on the latest 2.6.30 version?
Yes, at least with 2.6.30-rc3. I reloaded snd-hda-intel a few times, and at some point /etc/init.d/alsa-utils start complained, I guess because some index numbers in the mixer changed. Attached is an example diff.
Regards, Tino
At Fri, 24 Apr 2009 16:21:13 +0200, Tino Keitel wrote:
On Fri, Apr 24, 2009 at 16:01:40 +0200, Takashi Iwai wrote:
[...]
The codec communication looks a bit unstable on this device... Does this still happen on the latest 2.6.30 version?
Yes, at least with 2.6.30-rc3. I reloaded snd-hda-intel a few times, and at some point /etc/init.d/alsa-utils start complained, I guess because some index numbers in the mixer changed.
And this happens because the codec doesn't respond properly any more. So, something triggers to screw up the communication with the codec. I have no idea right now. Possibly you can bisect the changes against sound/pci/hda/patch_sigmatel.c...
Attached is an example diff.
This diff looks OK. The difference is just the current PCM stream you are playing. Others are identical.
thanks,
Takashi
On Fri, Apr 24, 2009 at 16:41:14 +0200, Takashi Iwai wrote:
At Fri, 24 Apr 2009 16:21:13 +0200, Tino Keitel wrote:
On Fri, Apr 24, 2009 at 16:01:40 +0200, Takashi Iwai wrote:
[...]
The codec communication looks a bit unstable on this device... Does this still happen on the latest 2.6.30 version?
Yes, at least with 2.6.30-rc3. I reloaded snd-hda-intel a few times, and at some point /etc/init.d/alsa-utils start complained, I guess because some index numbers in the mixer changed.
And this happens because the codec doesn't respond properly any more. So, something triggers to screw up the communication with the codec. I have no idea right now. Possibly you can bisect the changes against sound/pci/hda/patch_sigmatel.c...
The problem is that I don't have a reliable way to trigger this bug. It just happens sometimes.
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
So it seems that all newer kernels are pretty broken on this hardware regarding sound.
Regards, Tino
At Tue, 28 Apr 2009 02:23:09 +0200, Tino Keitel wrote:
On Fri, Apr 24, 2009 at 16:41:14 +0200, Takashi Iwai wrote:
At Fri, 24 Apr 2009 16:21:13 +0200, Tino Keitel wrote:
On Fri, Apr 24, 2009 at 16:01:40 +0200, Takashi Iwai wrote:
[...]
The codec communication looks a bit unstable on this device... Does this still happen on the latest 2.6.30 version?
Yes, at least with 2.6.30-rc3. I reloaded snd-hda-intel a few times, and at some point /etc/init.d/alsa-utils start complained, I guess because some index numbers in the mixer changed.
And this happens because the codec doesn't respond properly any more. So, something triggers to screw up the communication with the codec. I have no idea right now. Possibly you can bisect the changes against sound/pci/hda/patch_sigmatel.c...
The problem is that I don't have a reliable way to trigger this bug. It just happens sometimes.
That's what I'm afraid of.
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
This could be rather a mixer setup issue. Please give alsa-info for the same setting on both kernels.
Takashi
On Tue, Apr 28, 2009 at 07:24:33 +0200, Takashi Iwai wrote:
[...]
This could be rather a mixer setup issue.
Of cause I already spent quite some time trying to get a usable line in signal level. With 2.6.27, I just set "Capture" as the record source and adjust its gain, where the gain level is already sufficent at 10-20. With 2.6.29, I raised it to 100 but didn't get a usable line in level.
Please give alsa-info for the same setting on both kernels.
Attached.
Regards, Tino
On Tue, Apr 28, 2009 at 02:23:09 +0200, Tino Keitel wrote:
[...]
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
FYI: I just tried 2.6.28 and line-in was still broken. So the last working kernel is 2.6.27.
Regards, Tino
On Thu, May 07, 2009 at 00:27:53 +0200, Tino Keitel wrote:
On Tue, Apr 28, 2009 at 02:23:09 +0200, Tino Keitel wrote:
[...]
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
FYI: I just tried 2.6.28 and line-in was still broken. So the last working kernel is 2.6.27.
I tried this:
git bisect start v2.6.28 v2.6.27 sound/pci/hda/patch_sigmatel.c
The result is commit 4f1e6bc3646ab50b8181555ab7e6eeab68b8632a.
I can't use git revert because of conflicts, so I crafted the attached patch against 2.6.30-rc4-00288-g413f81e, and now line-in works.
Regards, Tino
On Thu, 2009-05-07 at 09:23 +0200, Tino Keitel wrote:
On Thu, May 07, 2009 at 00:27:53 +0200, Tino Keitel wrote:
On Tue, Apr 28, 2009 at 02:23:09 +0200, Tino Keitel wrote:
[...]
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
FYI: I just tried 2.6.28 and line-in was still broken. So the last working kernel is 2.6.27.
I tried this:
git bisect start v2.6.28 v2.6.27 sound/pci/hda/patch_sigmatel.c
The result is commit 4f1e6bc3646ab50b8181555ab7e6eeab68b8632a.
I can't use git revert because of conflicts, so I crafted the attached patch against 2.6.30-rc4-00288-g413f81e, and now line-in works.
Regards, Tino
It's funny you mention left audio broken with hda(testing out the imac91.patch, works good, but as soon as I boot into osx the left audio speaker sounds blown out) nice... ehhh...
(probably nothing of the sort, but you never know)
Justin P. Mattock
At Thu, 7 May 2009 09:23:53 +0200, Tino Keitel wrote:
On Thu, May 07, 2009 at 00:27:53 +0200, Tino Keitel wrote:
On Tue, Apr 28, 2009 at 02:23:09 +0200, Tino Keitel wrote:
[...]
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
FYI: I just tried 2.6.28 and line-in was still broken. So the last working kernel is 2.6.27.
I tried this:
git bisect start v2.6.28 v2.6.27 sound/pci/hda/patch_sigmatel.c
The result is commit 4f1e6bc3646ab50b8181555ab7e6eeab68b8632a.
I can't use git revert because of conflicts, so I crafted the attached patch against 2.6.30-rc4-00288-g413f81e, and now line-in works.
Great, thanks for finding it out!
I'll take a deeper look later.
Takashi
At Thu, 7 May 2009 09:23:53 +0200, Tino Keitel wrote:
On Thu, May 07, 2009 at 00:27:53 +0200, Tino Keitel wrote:
On Tue, Apr 28, 2009 at 02:23:09 +0200, Tino Keitel wrote:
[...]
I just saw another, major problem: line in doesn't work anymore with 2.6.29 and also 2.6.30-rc3 (no usable input level). It works with 2.6.27.20.
FYI: I just tried 2.6.28 and line-in was still broken. So the last working kernel is 2.6.27.
I tried this:
git bisect start v2.6.28 v2.6.27 sound/pci/hda/patch_sigmatel.c
The result is commit 4f1e6bc3646ab50b8181555ab7e6eeab68b8632a.
Could you try the patch below instead?
The problem is that BIOS on your machine sets this pin both for input and output. Since it's set as input, the driver respects the BIOS setup and skips to override.
So, it's a BIOS problem, as usual :)
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 76487de..e58e008 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -4084,7 +4084,9 @@ static int stac92xx_init(struct hda_codec *codec) pinctl = snd_hda_codec_read(codec, nid, 0, AC_VERB_GET_PIN_WIDGET_CONTROL, 0); /* if PINCTL already set then skip */ - if (!(pinctl & AC_PINCTL_IN_EN)) { + if (!(pinctl & AC_PINCTL_IN_EN) || + (pinctl & AC_PINCTL_OUT_EN)) { + pinctl &= ~AC_PINCTL_OUT_EN; pinctl |= AC_PINCTL_IN_EN; stac92xx_auto_set_pinctl(codec, nid, pinctl);
Hi.
On Thu, 2009-05-07 at 12:45 +0200, Takashi Iwai wrote:
The problem is that BIOS on your machine sets this pin both for input and output. Since it's set as input, the driver respects the BIOS setup and skips to override.
'scuse the ignorance, but this makes me ask: Are pins logically unrelated to jacks? I have a Dell M1530, and it has some jacks that can work as either inputs or outputs. Under M$, when I plug something in, a dialog box pops up asking me whether I connected a mic, line in or an output jack (I forget the details). Sounds like Tino's problem is what I'd expect from my BIOS. But I'm probably completely ignorant :)
Regards,
Nigel
At Thu, 07 May 2009 21:54:40 +1000, Nigel Cunningham wrote:
Hi.
On Thu, 2009-05-07 at 12:45 +0200, Takashi Iwai wrote:
The problem is that BIOS on your machine sets this pin both for input and output. Since it's set as input, the driver respects the BIOS setup and skips to override.
'scuse the ignorance, but this makes me ask: Are pins logically unrelated to jacks?
Yes, they are.
I have a Dell M1530, and it has some jacks that can work as either inputs or outputs. Under M$, when I plug something in, a dialog box pops up asking me whether I connected a mic, line in or an output jack (I forget the details). Sounds like Tino's problem is what I'd expect from my BIOS. But I'm probably completely ignorant :)
The problem there is that the BIOS sets the current pin direction for both input and output, but you can't play and record at the same time on a jack. It's not about the capability.
BIOS is supposed to set all the pins properly ready for use, but it's not so on Mac.
Takashi
Hi.
On Thu, 2009-05-07 at 14:16 +0200, Takashi Iwai wrote:
At Thu, 07 May 2009 21:54:40 +1000, Nigel Cunningham wrote:
Hi.
On Thu, 2009-05-07 at 12:45 +0200, Takashi Iwai wrote:
The problem is that BIOS on your machine sets this pin both for input and output. Since it's set as input, the driver respects the BIOS setup and skips to override.
'scuse the ignorance, but this makes me ask: Are pins logically unrelated to jacks?
Yes, they are.
I have a Dell M1530, and it has some jacks that can work as either inputs or outputs. Under M$, when I plug something in, a dialog box pops up asking me whether I connected a mic, line in or an output jack (I forget the details). Sounds like Tino's problem is what I'd expect from my BIOS. But I'm probably completely ignorant :)
The problem there is that the BIOS sets the current pin direction for both input and output, but you can't play and record at the same time on a jack. It's not about the capability.
BIOS is supposed to set all the pins properly ready for use, but it's not so on Mac.
Thanks! :)
Nigel
On Fri, 2009-05-08 at 06:42 +1000, Nigel Cunningham wrote:
Hi.
On Thu, 2009-05-07 at 14:16 +0200, Takashi Iwai wrote:
At Thu, 07 May 2009 21:54:40 +1000, Nigel Cunningham wrote:
Hi.
On Thu, 2009-05-07 at 12:45 +0200, Takashi Iwai wrote:
The problem is that BIOS on your machine sets this pin both for input and output. Since it's set as input, the driver respects the BIOS setup and skips to override.
'scuse the ignorance, but this makes me ask: Are pins logically unrelated to jacks?
Yes, they are.
I have a Dell M1530, and it has some jacks that can work as either inputs or outputs. Under M$, when I plug something in, a dialog box pops up asking me whether I connected a mic, line in or an output jack (I forget the details). Sounds like Tino's problem is what I'd expect from my BIOS. But I'm probably completely ignorant :)
The problem there is that the BIOS sets the current pin direction for both input and output, but you can't play and record at the same time on a jack. It's not about the capability.
BIOS is supposed to set all the pins properly ready for use, but it's not so on Mac.
Thanks! :)
Nigel
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
One thing that they did(which is nice) is finally, if you mute or turn down the master volume, once rebooting you don't have that BONG or introduction noise.
Justin P. Mattock
On Thu, May 07, 2009 at 22:42:08 +0200, Tino Keitel wrote:
On Thu, May 07, 2009 at 12:45:08 +0200, Takashi Iwai wrote:
[...]
Could you try the patch below instead?
It doesn't work.
Sorry, my mixer setup was wrong. The patch works.
Regards, Tino
At Thu, 7 May 2009 22:53:49 +0200, Tino Keitel wrote:
On Thu, May 07, 2009 at 22:42:08 +0200, Tino Keitel wrote:
On Thu, May 07, 2009 at 12:45:08 +0200, Takashi Iwai wrote:
[...]
Could you try the patch below instead?
It doesn't work.
Sorry, my mixer setup was wrong. The patch works.
Thanks for testing. I merged the patch now to sound git tree.
Takashi
participants (5)
-
Justin P. Mattock -
Nigel Cunningham -
Takashi Iwai -
Tino Keitel -
Tino Keitel