Bug 12061

The power save feature itself has been unchanged, so it must be codec specific.
Please run alsa-info.sh with --no-upload option and attach the generated file, preferably before and after the power saving.
The script is found in
    http://www.alsa-project.org/alsa-info.sh

And, are you sure that this worked in 2.6.27 kernel?
If yes, any chance to run alsa-info.sh on the old kernel?

Created attachment 18928 [details]
After modprobe with power_save=0

Created attachment 18929 [details]
After setting power_save 60 over sysfs

Created attachment 18930 [details]
After muting main and wait 60 secs

Created attachment 18931 [details]
2.6.28-rc5: after modprobe with power_save=0

Created attachment 18932 [details]
2.6.28-rc5: after setting power_save 60 over sysfs

Created attachment 18933 [details]
2.6.28-rc5: after muting main and wait 60 secs (and cracking sound)

I've tested it with 2.6.27.6 and 2.6.28-rc5.

1. modprobe snd_hda_intel power_save=0
2. setting power_save to 60 over sysfs
3. muting main channel and wait 60 secs

Note that setting power_save option to 0 via sysfs doesn't change the real power state.  You'd need to access to the device once and close to trigger the power-saving.

The recent code for IDT 92HD71bxx codec has more power-saving feature, toggling the power state of ADC/DACs dynamically.  This might cause the clicks.

Anyway, try the latest Linus git tree.  Some fixes for your codec have been merged there.

Also, you can try sound-2.6.git tree (pull it onto Linus git tree) below for testing the latest ALSA driver:
    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git master

(In reply to comment #9)
> Note that setting power_save option to 0 via sysfs doesn't change the real
> power state.  You'd need to access to the device once and close to trigger
> the
> power-saving.

That's the reason why I muted the main channel - that opened the device and triggered the power-saving..

But I'll try the git sources.

OK.

Also please check whether the noise appears even if you mute the output and do power-saving.  If the noise appears even with mute, maybe it's EAPD.

And, does the similar click appear at the power-up?  Or only at power down?

(In reply to comment #11)
> OK.
> 
> Also please check whether the noise appears even if you mute the output and
> do
> power-saving.  If the noise appears even with mute, maybe it's EAPD.

yes, this noise appears also on muted output after the specified timeout.

> And, does the similar click appear at the power-up?  Or only at power down?

The click appears at power-up (boot process) after loading the module and the specified timeout.

OK, and does the noise appear also when you play a sound again *after* the power-saving?  This does effectively similar like boot-up.  I guess you'll hear a click noise as well.

(BTW, you don't have to set such a high value to power_save for testing.  Usually I set 1 or 2 for testing so that I see the power-saving is done almost immediately ;)

(In reply to comment #13)
> OK, and does the noise appear also when you play a sound again *after* the
> power-saving?  This does effectively similar like boot-up.  I guess you'll
> hear
> a click noise as well.

it happens on each power_save. But not on wakeup. It even happens if a sound is played while the main output is muted.

And it happens with the latest Linux git.

Created attachment 18936 [details]
2.6.28-git: after modprobe with power_save=0

Created attachment 18937 [details]
2.6.28-git: after setting power_save 60 over sysfs

Created attachment 18938 [details]
2.6.28-git: after muting main and wait 60 secs (and cracking sound)

Created attachment 18939 [details]
2.6.28-git: after setting power_save 60 over sysfs

Sorry, uploaded the wrong file

Created attachment 18940 [details]
2.6.28-alsagit: after modprobe with power_save=0

Created attachment 18941 [details]
2.6.28-alsagit: after setting power_save 60 over sysfs

Created attachment 18942 [details]
2.6.28-alsagit: after muting main and wait 60 secs (and cracking sound)

(In reply to comment #9)
> Also, you can try sound-2.6.git tree (pull it onto Linus git tree) below for
> testing the latest ALSA driver:
>     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git master

just tried it - same behavior/cracking sound.

Handled-By : Takashi Iwai <tiwai@suse.de>

Well I had to say I hear this cracking sound as well - my machine is T61


# cat /proc/asound/cards 
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xfe020000 irq 17

 
Currently I'm running -rc6 and the sound is still there.
Though the easiest solution is to disable powersaving...

No "regression" regarding Thinkpad.  This has been so.

For Dell, it's likely a side-effect of more power-saving than the earlier version.

And, yes, if you don't want click noises, set power_save=0.  Some distros change the parameter dynamically, but I won't cover it here.

The only special thing done in the suspend in the codec side is the GPIO reset.
Could you try the patch below?  It's against the latest sound tree.

Created attachment 19001 [details]
Disable GPIO reset at suspend

(In reply to comment #26)
> The only special thing done in the suspend in the codec side is the GPIO
> reset.
> Could you try the patch below?  It's against the latest sound tree.

I successfully applies the patch and it still occurs.
If you need the alsa-info files I could upload them..

I'm still wondering what make difference between 2.6.27 and 28.

Could you double-check the following?
- this doesn't happen on 2.6.27.x with the same configuration
- the click occurs at power-down, not at power-up in the power-saving mode

Also, you can try to set power_save_controller=0 option.

(In reply to comment #29)
> I'm still wondering what make difference between 2.6.27 and 28.
> 
> Could you double-check the following?
> - this doesn't happen on 2.6.27.x with the same configuration
> - the click occurs at power-down, not at power-up in the power-saving mode
> 
> Also, you can try to set power_save_controller=0 option.

I tried it and still: 2.6.27.6 has no cracking sound. It's no matter whether power_save_controller is set.

OK, and it happens certainly only at power-down?

And, try sound git tree again, just to be sure since there have been a bunch of fixes in these weeks.

Could you try the patch below?  At least, the caching is useless for power mode, so a part of it is anyway a necessary fix.

Created attachment 19064 [details]
Fix unnecessary cache and power-change in 92hd71xx PM code

BTW, also please check whether the suspend/hibernate works even after with this patch.

Any news?

(In reply to comment #33)
> Created an attachment (id=19064) [details]
> Fix unnecessary cache and power-change in 92hd71xx PM code

I just applied the patch to 2.6.28-rc7 and it still cracks.
But I had some time to mess around in the module sources.

It does not occur if I directly return from snd_hda_codec_write_cache. Digging a little further I found "snd_hda_power_down(codec);" inside this method.
Commenting this line fixed the cracking sound on power_save.

Of course, commenting it out changes the behavior.  The drawback is that you get no longer power-saving :)  It keeps the reference count only up.

So, I wonder whether you really got any power-saving feature on 2.6.27.x.  It might be just a coincidence, that the power-saving is "fixed" on 2.6.28 while it didn't work on the older version...

Could you confirm whether the power-saving worked on 2.6.27.x?

How can I test whether power-saving worked in 2.6.27.x?

Simply put some printk() in the stac92xx_suspend() and stac92xx_resume() :-)

To be sure, could you try the latest sound.git tree master branch and check whether the problem still remains?

Jens, any news here?

k(In reply to comment #39)
> Simply put some printk() in the stac92xx_suspend() and stac92xx_resume() :-)

I can't find stac92xx_suspend - but some other suspend methods were called (power_save=10):
Dec 14 12:50:35 jtb [   99.280105] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
Dec 14 12:50:35 jtb [   99.280147] HDA Intel 0000:00:1b.0: setting latency timer to 64
Dec 14 12:50:45 jtb [  109.373581] hda_codec: called hda_power_work
Dec 14 12:50:45 jtb [  109.373592] hda_codec: called hda_call_codec_suspend
Dec 14 12:50:45 jtb [  109.387159] hda_codec: called hda_power_work
Dec 14 12:50:45 jtb [  109.387170] hda_codec: called hda_call_codec_suspend

(In reply to comment #39)
> To be sure, could you try the latest sound.git tree master branch and check
> whether the problem still remains?

just tried it - still the cracking sound..

Thanks.  Indeed stac92xx_suspend() doesn't exist in 2.6.27.x code, sorry.
You analysis implies that the suspend code is actually called (as I suppose it's about 2.6.27.x).  And, in the latest sound.git code, the suspend path does almost same.

So, a difference is not in the suspend/resume path, but additional initializations done in the recent code.

Could you try the patch below (stac-power-down-suspend.diff) for the latest sound.git tree?

Created attachment 19308 [details]
Add analog-pins power-down in suspend callback

Sorry for the delay.
The problem still exists with analog-pins power-down patch (and I made sure that the function is really called).

I have a somewhat similar issue on my HP 2510p notebook. When I suspend the notbook to RAM, I get a single loud crack on the speaker at the time it powers off. When I shut down the notebook, the crack is not there.

00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03)

Head of /proc/asound/Intel/codec#0 (snd_hda_intel):
Codec: Analog Devices AD1981
Address: 0
Vendor Id: 0x11d41981
Subsystem Id: 0x103c30c9
Revision Id: 0x100200

If you'd prefer me to open a separate bug report for this issue then please let me know.

same as Frans Pop. is there any additional information we can provide?

Hi,

Any news on this?
I also experience these cracks, when booting, at shutdown, when hibernating and resuming from hibernation.

Cheers,
Julien

Still there in 2.6.29 :(

Note that I can head these cracks even with power_save=0;

should I open a separate bug report?

Cheers,
Julien

I get the cracking sound on my Dell Latitude E6500 when suspending to ram with kernel 2.6.28. I tried loading the module with power_save=0, but didn't make any difference.

This bug has been around for quite some time, and since it's working normally under 2.6.27 it shouldn't be that to figure this out?

Let me know if there is any information I can provide to help.

/Stian

I've also get cracking sound on my Dell Latitude E6500.
I am not sure if this is the same bug.

I hear the (quite loud) crack when powering up the device or when powering it down (power_save is set to 10 automatically when I am running on battery).

With 2.6.27, those cracks were not loud at all and barley noticeable.
With 2.6.28, the cracks were really loud and annoying.

I bisected the kernel out found the point were the cracks got loud:

[4b33c7675d2b0d4a9cb4e38cd73aa1d940f9278d]
ALSA: hda: add mixers for analog mixer on 92hd75xx codecs

I'll also attach my alsa-info.

Anything else I can do to help with this?

Created attachment 22648 [details]
My also-info.txt

I've also tried the latest Git tree from Linus, but the problem is the same there.

Since I bisected this to a specific commit, I think the status should be something different form NEEDINFO.

Changing to "assigned".

Try the latest sound git tree.  There are lots of changes since 2.6.31.

> Try the latest sound git tree.  There are lots of changes since 2.6.31.

Thanks, my problems seem to be fixed with the latest sound git tree :)

I'm currently using 2.6.32-rc6 and just found out that power_save doesn't crack anymore. Closed for me.

Many thanks to you, Takashi!

(In reply to comment #59)
> I'm currently using 2.6.32-rc6 and just found out that power_save doesn't
> crack
> anymore. Closed for me.

Seems like it would be a good idea to document what changes fixed this, before closing the bug report.