Audio codec draining power when not in use

Powertop output. For some reason it show 1W for the codecs, while GUI shows 1.67W consistently.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the release candidate kernel versus the daily build. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

I have done the following:
1) Removed the proprietary nvidia drivers
2) Installed RC and daily kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc10-oneiric/ and http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
3) For each of these ran powertop on idle system. The reported wattage varies 1.4W-1.7W (originally was 1.6W), in all cases the codecs are shown as being used 100% of time. I am attaching the powertop reports. The reports always shows 1W while GUI shows 1.4-1.7, I include the GUI value in the file name.

I didn't re-run appport for these kernels, please let me know if I should. I am keeping them around should I do any other testing with them.

laurynas@laurynas-ThinkPad-T410:~/Downloads$ ls -l *.deb
-rw-rw-r-- 1 laurynas laurynas 11298080 2011-10-18 20:29 linux-headers-3.1.0-0301rc10_3.1.0-0301rc10.201110181253_all.deb
-rw-rw-r-- 1 laurynas laurynas 897630 2011-10-18 20:29 linux-headers-3.1.0-0301rc10-generic_3.1.0-0301rc10.201110181253_amd64.deb
-rw-rw-r-- 1 laurynas laurynas 11295418 2011-10-18 20:33 linux-headers-3.1.0-999_3.1.0-999.201110171146_all.deb
-rw-rw-r-- 1 laurynas laurynas 898358 2011-10-18 20:32 linux-headers-3.1.0-999-generic_3.1.0-999.201110171146_amd64.deb
-rw-rw-r-- 1 laurynas laurynas 37052966 2011-10-18 20:27 linux-image-3.1.0-0301rc10-generic_3.1.0-0301rc10.201110181253_amd64.deb
-rw-rw-r-- 1 laurynas laurynas 37008344 2011-10-18 20:33 linux-image-3.1.0-999-generic_3.1.0-999.201110171146_amd64.deb

Powertop report with the RC kernel

Powertop report with the daily kernel

I have installed a custom kernel for an unrelated issue and applied all the released package updates and the powertop report has changed.

The kernel is from bug 844957 : http://people.canonical.com/~ogasawara/lp844957/

Now the powertop reports 0 mW for the sound codec, and the overall battery drain reported is lower too (although not by 3.3W lower).

OTOH meanwhile I have found bug 834725, so I am not sure how much powertop reports can be trusted.

Later I will reboot back to official kernel to check if it is kernel or package updates that have caused this change.

I have to take back my last comment. After the reboots to the official kernel and back I still get 100% and >1W reports. Must be something then.

Powertop reporting 5.47 watts (!) at 100% on Thinkpad T60. Running Xubuntu with kernel 3.0.0-12-generic

Sorry that was incorrect. Unable to delete comment.

powertop 1.97 reporting 4.17 watts and 100% usage on codec hwc0d0, on a thinkpad t410, running ubuntu oneiric. Powertop 1.13 doesn't seem to see it (though there's a large category for 'rescheduling wakeups', not sure if htat's related)

So the basic issues here are that we need to get accurate and consistent power measurements that we know are reliable. I suggest running powerstat from my PPA: https://launchpad.net/~colin-king/+archive/powermanagement

* Make sure the machine is not running any unnecessary power sucking applications (like webpages with flash) etc
* Run powerstat - it will take ~8 minutes so that we can get a long battery capacity change to get a more accurate measurement.

..and then we can start looking seeing if this is really as bad as powertop reports.

I think it might be that powertop is on crack here. I see that at the top of powertop's overview all the time (with only a few terminals open), but on powertop-1 it never shows up. Here's a snapshot of both, taken at the same time (on precise):

powertop:
                Usage Events/s Category Description
             2316 rpm Device Laptop fan
            100.0% Device Audio codec hwC0D0: Conexant
             16.3 ms/s 85.9 Process /usr/bin/X :0 -auth /var/run/lightdm/root/:0 vt7 -novtswitch -background
             16.9 ms/s 59.5 Process compiz

powertop-1:
Top causes for wakeups:
  29.5% (136.3) [Rescheduling interrupts] <kernel IPI>
  17.0% ( 78.7) [i915] <interrupt>
  11.5% ( 53.0) compiz
   8.1% ( 37.7) [ehci_hcd:usb2] <interrupt>

It's been a while since I reported this, now this machine has received kernel/BIOS/RAM/rest of ubuntu package upgrades, and I cannot reproduce the apparent audio codec power hog with powertop. OTOH, now it's fixated on unused ethernet card, reporting that it is taking 15-16W. Of course all powertop suggestions were followed.

I run powerstat anyway:
Running for 300 seconds (30 samples at 10 second intervals).
ACPI battery power measurments will start in 180 seconds time

  Time User Nice Sys Idle IO Run Ctxt/s IRQ/s Fork Exec Exit Watts
18:51:50 2.7 0.1 0.2 97.0 0.0 1 432 363 0 0 0 13.45
18:52:00 2.5 0.0 0.1 96.8 0.6 1 430 361 0 0 0 13.14
18:52:10 2.8 0.1 0.2 97.0 0.0 2 437 368 0 0 0 13.10
18:52:20 2.4 0.0 0.2 97.1 0.4 1 424 365 0 0 0 13.08
18:52:30 2.5 0.0 0.2 97.3 0.0 1 440 374 0 0 0 13.02
18:52:40 2.1 0.0 0.2 96.8 0.9 1 389 331 0 0 0 12.95
18:52:50 2.8 0.0 0.2 96.7 0.1 1 462 389 2 2 2 13.08
18:53:00 2.6 0.0 0.3 96.8 0.3 2 465 382 4 4 4 13.57
18:53:10 2.7 0.0 0.2 97.1 0.0 1 418 345 0 0 0 13.90
18:53:20 2.3 0.0 0.2 97.6 0.0 1 399 337 0 0 0 14.34
18:53:30 2.8 0.1 0.2 96.2 0.8 2 454 385 0 0 0 14.73
18:53:40 2.1 0.0 0.2 97.7 0.0 1 374 309 0 0 0 15.09
18:53:50 2.4 0.1 0.2 97.4 0.0 1 429 369 1 0 0 15.48
18:54:00 2.0 0.0 0.2 97.1 0.8 2 412 355 0 0 0 15.11
18:54:10 2.8 0.0 0.2 96.8 0.2 2 437 366 0 0 0 14.56
18:54:20 2.4 0.0 0.1 97.6 0.0 2 408 344 0 0 0 14.13
18:54:30 2.7 0.0 0.3 96.3 0.8 1 435 353 0 0 0 13.82
18:54:40 2.3 0.0 0.2 97.3 0.2 1 394 338 0 0 0 13.58
18:54:50 2.8 0.1 0.3 96.7 0.2 1 439 385 0 0 0 13.76
18:55:00 2.4 0.0 0.1 96.8 0.8 1 433 375 0 0 0 14.33
18:55:10 4.4 0.0 0.2 95.4 0.0 3 447 400 0 0 0 14.95
18:55:20 2.2 0.0 0.3 97.4 0.2 1 391 333 0 0 0 15.56
18:55:30 2.8 0.0 0.3 96.9 0.1 1 465 401 0 0 0 15.87
18:55:40 2.0 0.0 0.1 97.9 0.0 2 411 353 0 0 0 15.63
18:55:50 3.0 0.1 0.3 96.7 0.0 1 512 431 2 2 5 15.34
18:56:00 2.5 0.0 0.3 96.3 0.9 1 461 376 4 4 5 15.22
18:56:10 2.7 0.1 0.3 97.0 0.0 2 406 325 0 0 0 14.59
18:56:20 2.4 0.0 0.2 97.5 0.0 1 371 303 0 0 0 14.08
18:56:30 3.0 0.0 0.3 95.4 1.3 2 439 353 0 0 1 13.68
18:56:40 2.1 0.0 0.3 97.6 0.0 1 388 316 1 0 0 13.34
-------- ----- ----- ----- ----- ----- ---- ------ ------ ---- ---- ---- ------
 Average 2.6 0.0 0.2 96.9 0.3 1.4 426.7 359.5 0.5 0.4 0.6 14.22
  StdDev 0.4 0.0 0.1 0.6 0.4 0.5 30.5 28.3 1.1 1.1 1.4 0.90
----...

I'm also having this Issue with the last nightly of precise pangolin.

   Usage Events/s Category Description
100.0% Device Audio codec hwC0D1: Conexant

I have just upgraded from Maverick to Natty to Oneiric, since Maverick just lost security support. My fan is running at high speed blowing hot air. I have now removed my battery from my laptop and I'm strictly running on AC power. Powertop shows:
Summary: 355,9 wakeups/second, 0,0 GPU ops/second and 0,0 VFS ops/sec

                Usage Events/s Category Description
            100,0% Device Audio codec hwC0D0: IDT
              3,8 ms/s 86,3 Timer hrtimer_wakeup
             28,9 ms/s 69,3 Process /usr/lib/firefox-11.0/firefox
              2,9 ms/s 46,3 Timer tick_sched_timer
             22,8 ms/s 33,0 Process compiz
             10,7 ms/s 31,8 Process /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp v
              1,5 ms/s 21,2 Interrupt [44] radeon
             14,3 ms/s 8,2 Process /usr/lib/unity/unity-panel-service
             11,1 ms/s 3,0 Process //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --s
            179,1 µs/s 7,2 kWork ieee80211_iface_work
              0,9 ms/s 6,5 Interrupt [6] tasklet(softirq)
             33,9 µs/s 4,2 kWork console_callback
...

Today after just a few minutes uptime and only using Unity and terminal I get:
ayers@schiefer:~$ uptime
 07:03:34 up 18 min, 2 users, load average: 0.01, 0.09, 0.20
ayers@schiefer:~$ sudo sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +75.0°C

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +74.0°C (high = +70.0°C)
                       (crit = +115.5°C, hyst = +110.5°C)

(starting firefix [without flash installed on the system and simply typing this report] this soon rises to
ayers@schiefer:~$ uptime && sudo sensors
 07:05:37 up 20 min, 2 users, load average: 0.20, 0.11, 0.19
acpitz-virtual-0
Adapter: Virtual device
temp1: +76.0°C

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +75.5°C (high = +70.0°C)
                       (crit = +115.5°C, hyst = +110.5°C)

another two minutes:
ayers@schiefer:~$ uptime && sudo sensors
 07:07:42 up 22 min, 2 users, load average: 0.04, 0.08, 0.17
acpitz-virtual-0
Adapter: Virtual device
temp1: +77.0°C

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +76.6°C (high = +70.0°C)
                       (crit = +115.5°C, hyst = +110.5°C)

I rebooted and before loging in (i.e. only the greeter was running) I switched to the console and only monitored the system for a bit with sesnors and top... and 8 minutes later:

 07:18:55 up 8 min, 1 user, load average: 0.01, 0.34, 0.28
acpitz-virtual-0
Adapter: Virtual device
temp1: +80.0°C

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +79.6°C (high = +70.0°C)
                       (crit = +115.5°C, hyst = +110.5°C)

then login and file this report:
 07:22:46 up 12 min, 2 users, load average: 0.28, 0.56, 0.41
acpitz-virtual-0
Adapter: Virtual device
temp1: +85.0°C

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +83.5°C (high = +70.0°C)
                       (crit = +115.5°C, hyst = +110.5°C)

(Under maverick I used this system to run 2 vm simultaniously and surf with about 12 tabs and the fan only got to this level if one oof the vm was compiling or some WebM Video was playing)

This bug is still present in precise. However, the following workaround works for me:
* log in
* echo 1 | sudo tee /sys/module/snd_hda_intel/parameters/power_save
* echo Y | sudo tee /sys/module/snd_hda_intel/parameters/power_save_controller
* pkill pulseaudio
* log out & log in again (so pulseaudio gets restarted)

However just inserting "options snd-hda-intel power_save=1 power_save_controller=Y" in /etc/modprobe.d/alsa-base.conf doesn't work. Why?

Hi can those bugs be merged with ?
https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631

--
http://rzr.online.fr/q/hda

The workaround provided by Lauris Smilga works for me too.
My X220 reports battery life increase from 3 hours to 5.30.

How can we set those options permanently?

I am in the same boat as Lauris and Smilga,

running 12.04 amd64 on a thinkpad X200, setting the options suggested have given me huge(1.5hrs) battery increases and reduced overall heat. But I am at a loss on how to make perminant.

attempted setting in modprobe.d, rc.local, and sysfs.conf to no avail

Lauris Smilga's solution doesn't help me. I'm still seeing the audio codec usage, at 2W

Thinkpad T420

Hm the workaround seems to work after I put the computer to sleep and reactivated it.

The workaround from Lauris Smilga works for me (Samsung Series 7 Chronos 700Z3A-S02DE). However I dont find it appreaciate to log-out and log back in to get this fixed. powertop estimates 1.14W usage.

uname -a
Linux ck 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

lspci -mvknn | grep Audio -B8
Device: 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [1c2d]
SVendor: Samsung Electronics Co Ltd [144d]
SDevice: Device [c0b3]
Rev: 04
ProgIf: 20
Driver: ehci_hcd

Device: 00:1b.0
Class: Audio device [0403]
Vendor: Intel Corporation [8086]
Device: 6 Series/C200 Series Chipset Family High Definition Audio Controller [1c20]

Here is a status of this problem on my laptop with the latest quantal updates. I have attached powertop's HTML output. What I find confusing is that audio devices are listed both at 100% and 0% usage in the same powertop run:

100.0% PCI Device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller
100.0% PCI Device: Advanced Micro Devices [AMD] nee ATI RV635 HDMI Audio [Radeon HD 3600 Series]
[...]
0.0% Audio codec hwC0D0: Analog Devices
0.0% Audio codec hwC0D1: LSI

Can somebody explain this ?

I'm having the same issue but with Debian's kernel linux-image-3.2.0-4-amd64.

None of the tips provided here worked for me except the one by dfsmith:

https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/13

This seems to be an ALSA problem to me. Do the ALSA people and Intel know about this?

I've reported this issue up on alsa-devel. Here's the relevant thread:

   http://article.gmane.org/gmane.linux.alsa.devel/102984

After installing the 3.7-rc5 kernel, the excessive power consumption/heating problem went away here.

Is fixed for me in 3.7-rc8. Thanks Tomas for the hint.

I am experiencing this bug on Ubuntu 13.04 with kernel 3.8.0-22-generic. PowerTOP shows "Audio codec hwC0D1: Conexant" consumes 100% in power consumption summery.

Another "me too":

$ sudo powertop
Summary: 461.2 wakeups/second, 57.9 GPU ops/seconds, 0.0 VFS ops/sec and 10.0% CPU use
                Usage Events/s Category Description
             36.3 ms/s 242.7 Process /usr/lib/firefox/firefox
            100.0% Device Audio codec hwC0D3: Intel
            100.0% Device Audio codec hwC0D0: Realtek

$ uname -a
Linux zeno 3.8.0-21-generic #32-Ubuntu SMP Tue May 14 22:16:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ lspci | grep audio
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)

The workaround
$ echo 1 | sudo tee /sys/module/snd_hda_intel/parameters/power_save
$ echo Y | sudo tee /sys/module/snd_hda_intel/parameters/power_save_controller
$ pkill pulseaudio
worked, even without logging out and in (but not using audio).

Side note: using pm-powersave was a much bigger improvement on battery usage, 22W down to 13W.

confirmed on my HP 2730P

found this issue from PowerTOP 2.3

Confirmed on Lenovo x121e.

Powertop reports 100% usage of Audio codec hwC0D0: Conexant (pulseaudio )

Laurynas Biveinis, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/32 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Please reopen this bug. The original reported stated that this problem is fixed on his computer, but the problem persists on many other models. Problems have been reported with up-to-date 3.8 kernel on 13.04 installations.

Gioele Barabucci, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices
Ubuntu Community: https://wiki.ubuntu.com/ReportingBugs

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

Thank you for your understanding.

For all the people that are still affected by this bug about 100% usage of audio codecs, I filed a new bug at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1213719